Community
Participate
Working Groups
Created attachment 279611 [details] Fixed version of resolveState() I'm running eclipse 2019-06 on jdk1.8.0_221 (64-bit) as its VM. I have developed a plugin bundle P1 and a feature F1 which includes P1 and the equinox framework bundle (org.eclipse.osgi v3.13.300.v20190218-1622). P1 imports javax.xml.bind (no version qualified) When I export F1 using the "Export Wizard" on "Overview" tab, I get an error message like this: " Processing inclusion from feature F1: Bundle P1 failed to resolve.: Unsatisfied import package javax.xml.bind_0.0.0. " While this is feature is properly exported by "eclipse 2018-12". I'm relying on this to deliver my product and due to this, I had to switch to 2018-12 after development to export F1, which is not clearly an ideal approach! Since I was curious whether I'm doing something wrong or PDE is doing something related to Java-9+ support, I dug into it and I think I finally pinned the issue: During export method org.eclipse.pde.internal.build.site.PDEState.getJavaProfilePropertiesForVMPackage(String) is called at line 444 of org.eclipse.pde.internal.build.site.PDEState.resolveState() for Java-10, Java-11 and Java-12. getJavaProfilePropertiesForVMPackage(String) refers to resources bundled and shipped with PDE API tools (org.eclipse.pde.api.tools) which is irrelevant to what org.eclipse.osgi has in its profiles (it only has profiles defined up to Java-9). This inclusion results in "system bundle" be declared to not have "javax.xml.bind" exported for "Execution Environment (equinox_ee) = Java-12" by org.eclipse.osgi.internal.resolver.StateImpl.resetSystemExports() and org.eclipse.osgi.internal.resolver.StateImpl.resetSystemCapabilities() (which is correct by the way, this package is removed from framework exported packages for Java-11 and Java-12 but was never intended for this export in the first place). The loop in org.eclipse.pde.internal.build.site.PDEState.resolveState() also assumes that all later Java profiles are backward compatible with previous ones (line 448) which means, it assumes that "Java-12" and "Java-11" are backward compatible with "Java1.8", which is clearly not correct, at least for the list of "framework exported bundles" which includes javax.xml.bind in 1.8 but not for Java-12 and Java-11. This false assumption causes "system bundle" and any other bundle (P1 in my case) requiring EE of java 1.8 to be resolved to have "equinox_ee" set to the index of "Java-12" profile by org.eclipse.osgi.internal.module.ResolverImpl.resolveBundle(ResolverBundle, List<ResolverBundle>):1419 which is a better more recent match. Thus any later "import package" resolution for "javax.xml.bind" will fail by org.eclipse.osgi.internal.resolver.ImportPackageSpecificationImpl.isSatisfiedBy(BaseDescription, boolean) at line 169 which compares the "equinox_ee" of the candidate resolution with that of its bundle. I fixed the issue by preventing embedded resource in "org.eclipse.pde.api.tools" to contribute list of "framework exported bundles" for undeclared execution environments by "system bundle". The fixed file is attached for inspection. I don't know whether this fix complies with PDE and Equinox overall integration and design goals, but now F1 is exported like it did with eclipse 2018-12 and I'm happy with my effort. PS: I think the correct approach to this issue must consider the false backward compatibility assumption into account as I've mentioned above.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
