Community
Participate
Working Groups
Yesterday I had an inconsistent PDEClasspathContainer with the following jars and access rules: - ... - org.apache.servicemix.bundles.jdom_1.1.2.1.jar * Forbidden: **/* - org.apache.servicemix.bundles.jdom.source_1.1.2.1.jar * Accessible: org/jdom/output/* * Accessible: org/jdom/input/* * Accessible: org/jdom/* * Accessible: org/jdom/filter/* * Accessible: org/jdom/adapters/* * Accessible: org/jdom/transform/* * Accessible: org/jdom/xpath/* * Forbidden: **/* The affected plugin has a Require-Bundle: org.apache.servicemix.bundles.jdom The source jar obviously doesn't belong there and because it stole the access rules, the plugin couldn't compile. I spent quite some time debugging what went wrong there. Long story short: 1) org.apache.servicemix.bundles.jdom has Import-Packages for its own exports 2) org.apache.servicemix.bundles.jdom.source also exports org.jdom.** 3) I switched from a target with IUBundleContainers to one with oomph targlets The last point is significant because the order of bundles in oomph's targlet container seems non-deterministic. IUBundleContainer by comparison always orders the ".source" bundle after its real one (IUBundleContainer::generateResolvedBundles). The bundle order then affects the bundle's ID in PDEState. In my case, the source came first and had the lower ID. When choosing between multiple suppliers for a package import, the OSGi resolver picks the one with the lower id - all else being equal (--> org.eclipse.osgi.internal.module.VersionHashMap). The dependency hierarchy of org.apache.servicemix.bundles.jdom therefore contained its source bundle and StateHelper::getVisiblePackages returned the export of jdom.source instead causing the above access rules. --------------------------------------- "Fix the broken org.apache.servicemix.bundles.jdom bundle" seems like a perfectly valid resolution here but I was wondering why source bundles are part of the PDEState at all. Source bundles should never be relevant for resolution - and if they do resolve something, there's something broken like in this case. Simply omitting them all together from the state won't work because then they are never added to ExternalModelManager, breaking source lookups. Removing them later, immediately before resolveState() in PluginModelManager::initializeTable, seems to work though. Visible side effect: The source bundle will be unresolved afterwards. Dependency navigation or analysis in the source bundle's manifest editor won't work anymore. That's acceptable IMHO. The source bundle shouldn't have dependencies anyway (e.g. tycho generates them without any).
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.
