Community
Participate
Working Groups
Last nights nightly build failed because platform-ui checked code into workbench that required classes from org.eclipse.core.resources. We shouldn't have done this - resource code belongs in IDE. The problem is, workbench doesn't depend on resources and yet the code compiled fine so we weren't tipped off to our error. Looking at the Plug-in Dependencies tree under my workbench project I see resources is there but I don't see any reason for it to be. However, if I "Show plug-in dependency graph" from the Dependencies page of the plugin editor it is not listed. It's not listed in our manifest or our plugin.xml and it doesn't appear to be a re-exported requirement of a plug-in we depend on.
well, org.eclipse.ui.workbench.compatibility requires core.resources, so the host plugin (org.eclipse.ui.workbench) does have core.resources on its classpath at runtime. PDE is using the runtime state to determine what goes on the classpath, so either: 1. This is a PDE/Build bug, since PDE/Build should get the same result as PDE/UI if it were using the state. 2. The runtime shouldn't tell PDE to put core.resources on the classpath at development time, if the dependency is coming from the fragment. Adding Pascal/Tom for comment/action.
There is a possible explanation for PDE/Build and PDE/UI to get different results in this type of scenario. It depends on what methods each is calling to get depenency constraints from a BundleDescription object. The methods BundleDescription#getResolvedImports and BundleDescription#getResolvedRequires will return all dependancies which got resolved from a bundle host AND any attached fragments. The methods BundleDescription#getImportPackages and BundleDescription#getRequiredBundles only get the constraints for a particular bundle and do not include attached fragment constraits. I suspect PDE/UI is using ghet getResolvedImports and getResovlvedRequires methods and PDE/Build is using the getImportPackages and getRequiredBundles methods. I have not looked at the code for PDE/Build or PDE/UI to confirm this.
Tom, I did an investigation. The reason why core.resources is getting added on the classpath is because StateHelper#getVisiblePackages(BundleDescription) is returning packages from core.resources. This is technically correct at runtime, but should not be happening at development time. The org.eclipse.ui.workbench plug-in should not have on its classpath the dependencies (org.eclipse.core.resources) that are only required by its fragment (org.eclipse.ui.workbench.compatibility). I will move to you.
Changing the behavior of StateHelper#getVisiblePackages(BundleDescription) would cause other problems for PDE. Currently PDE uses this list of packages to buildup the classpath of the host. It then adds the host and all of its dependencies to the classpath of the fragment as well. If we stopped returning fragment constraints for the host then PDE would start failing to build fragments which require additional constraints. I really think we want to keep the State consistent between tools vs. runtime. I discussed this with Wassim. There may be some extra work that PDE UI could do to correctly compute the classpath for the host and fragment bundles. Right now PDE UI is making the assumption that all packages returned by getVisiblePackages are from constraints of the host. It could do some extra work here to make sure these packages are not from extra constraints of attached fragments.
Fixed. We no longer assume that packages returned by the state helper which do not correspond to Require-Bundle are coming via import-package. We now also go through the Import-Package statement manually and make sure no extra packages are making it to the classpath. This will exclude all packages that make it on the classpath from a fragment dependency.
