Community
Participate
Working Groups
Using HEAD, I got many problems with unresolved bundles inside an API baseline initialized using an SDK zip. I took me lots of time to realize that all problems came from missing Execution Environments set up in my self-hosting workspace. The ant task should report this to the user somehow. I would say all resolved errors for a state should be reported because unresolved bundles or resolved errors will have a direct impact on the accuracy of the API tools analysis.
Perhaps we could just support the skipped component mechanism we have for the analysis / use tasks. Basically if we detect an API component with ResolverErrors we dump it to a listing of SkippedComponents and write out the not_searched.xml file. That way the freeze check could report components that could not be checked and continue scanning, then the freeze report converter can notify the user however it pleases using the not_searched.xml file.
I think simply dumping the list of errors per bundle in the console in debug mode is good enough for now.
With the patch, I am getting: [apitooling.apifreeze] Errors for component : org.eclipse.ecf [apitooling.apifreeze] Missing Constraint: Require-Bundle: org.eclipse.ecf.identity; bundle-version="0.0.0" [apitooling.apifreeze] Errors for component : org.eclipse.ecf.provider.filetransfer [apitooling.apifreeze] Missing Constraint: Require-Bundle: org.eclipse.ecf; bundle-version="0.0.0" [apitooling.apifreeze] Errors for component : org.eclipse.ecf.filetransfer [apitooling.apifreeze] Missing Constraint: Require-Bundle: org.eclipse.ecf; bundle-version="0.0.0" [apitooling.apifreeze] Errors for component : org.eclipse.equinox.p2.transport.ecf [apitooling.apifreeze] Missing Constraint: Require-Bundle: org.eclipse.ecf; bundle-version="3.1.0" [apitooling.apifreeze] Errors for component : org.eclipse.ecf.provider.filetransfer.httpclient [apitooling.apifreeze] Missing Constraint: Require-Bundle: org.eclipse.ecf.provider.filetransfer; bundle-version="0.0.0" This would have been good enough for me to find out that something was wrong with my configuration.
Created attachment 194116 [details] Proposed fix If we don't dump the bundles with errors inside a specific file, we can get rid of the set where I store the api components.
Created attachment 194182 [details] Proposed fix Simplified patch that removes the usage of a Set to store the bundles with errors. This simply dumps the errors found to the console to help the user to find out that something is bad with his/her configuration.
Michael, please review.
The patch looks good to me. I think we should add this in for 3.7M7 to ensure that the freeze report is accurate (so we do not try to scan bundles with ResolverErrors)
running the test suite on the patch I get three failures (test1, test2, test3): API Tools Plugin Test Suite org.eclipse.pde.api.tools.tests.ApiToolsPluginTestSuite org.eclipse.pde.api.tools.anttasks.tests.ApiToolsAntTasksTestSuite org.eclipse.pde.api.tools.anttasks.tests.ApiToolingApiFreezeAntTaskTests test1(org.eclipse.pde.api.tools.anttasks.tests.ApiToolingApiFreezeAntTaskTests) junit.framework.AssertionFailedError: report.xml must exist at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.eclipse.pde.api.tools.anttasks.tests.ApiToolingApiFreezeAntTaskTests.runTaskAndVerify(ApiToolingApiFreezeAntTaskTests.java:53) <snip>
the test bundle has the following ResolverError: Missing Constraint: Require-Bundle: org.eclipse.ui; bundle-version="0.0.0"
Created attachment 194211 [details] Proposed fix When the scopes are used, the bundle version errors were not reported.
Created attachment 194212 [details] First jar First jar to dump into org.eclipse.pde.api.tools.tests\test-anttasks\apitooling.apifreeze\profile
Created attachment 194213 [details] Second jar Second jar to dump into org.eclipse.pde.api.tools.tests\test-anttasks\apitooling.apifreeze\profile
All tests pass with the new patch.
We need to decide if we want to make this optional. That might be an item for 3.8.
(In reply to comment #7) > The patch looks good to me. > > I think we should add this in for 3.7M7 to ensure that the freeze report is > accurate (so we do not try to scan bundles with ResolverErrors) Can this be done without switching the entire builder? If not, I think it's too late and should be done for RC1.
(In reply to comment #15) > Can this be done without switching the entire builder? What do you mean ? The fix is to walk all bundles after the baseline is initialized to report the ones with errors. Bundles are then added to an IApiScope that is processed to report potential API freeze changes. I tested the patch using 3.7M6 zip and the current I-build zip and it works fine. Kim only updates the builder with every milestone. This one is less important as it is only a matter of reporting resolution errors in the ant task. I don't think the builder has any resolution error with the baseline it is using.
(In reply to comment #16) > (In reply to comment #15) > > Can this be done without switching the entire builder? > What do you mean ? The fix is to walk all bundles after the baseline is > initialized to report the ones with errors. > Bundles are then added to an IApiScope that is processed to report potential > API freeze changes. > I tested the patch using 3.7M6 zip and the current I-build zip and it works > fine. > Kim only updates the builder with every milestone. > > This one is less important as it is only a matter of reporting resolution > errors in the ant task. I don't think the builder has any resolution error with > the baseline it is using. I thought the suggestion was to fix the results for the official builds. If that's not the case I'm fine.
Released for 3.7M7.
