Community
Participate
Working Groups
At least, that was one suggestion coming from bug 415008 comment 65. There might be other, more "direct" solutions (such as to "require" the "compatibility.state" bundle? Or ... to avoid the need for even that? I forget where we "left" that issue, but wanted to open this bug to track it. Let me know if I am mis-remembering. Thanks,
We need to resolve the dependency on org.eclipse.update.configurator not compatibility.state.
The first step should be to remove the use of the PDE Build plugin path finder. The logic in the PDE Core version is equivalent. If we were willing to drop support for reading the platform.xml in the target platform we could avoid using plugin path finder entirely. http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=4bc5978c61fb95654ac8ac6e9f4c520e3a86cb8f This fix in pde core removes the use of the build version of PluginPathFinder and also fixes the usage so we aren't doing multiple checks for the existence of a bundles.info.
I've added a real dependency on update configurator. It is required for any of the site building features. I left the runtime compatibility dependency as optional as it only affects the PluginRegistryConverter. http://git.eclipse.org/c/pde/eclipse.pde.build.git/commit/?id=5211a4a1d0befb0596b034545525f9eb9f9fb80f This might end up being the wrong call, as someone who was using pde build (but not the site building package) would now be required to have the compatibility fragment installed.