I would also be interested in hearing how the client
ended up with conflicting bundles.
Was it just from "installing different things"?
Or was it because their own build was
not precise enough? Or … something else?
It’s been several years and I no longer have access to the code, but hey are the same issues identified in the Orbit Bundle Naming page around evolution and naming clashes. In particular they had an internal team bundlify several libraries with same bundle names but conflicting version numbers.
It can be revisited, but I can't imagine that changing the bundle id would
ever be the right answer. I think the SpringSource Bundle Repository did the right thing prefixing its bundles. I think Orbit errs in using the publishing group’s reverse-DNS as the bundle’s symbolic name with no identifier indicating that it comes from Orbit. I think branding the Bundle-SymbolicName is a good for two reasons:
- It clearly identifies the bundles as being from Orbit (a ‘blessed’ bundle), and it avoids conflicts/clashes. Guava 15 is an example of being ‘blessed’: Guava has been including OSGi metadata since 12.0, and the Guava-provided jar looks virtually identical to the version in Orbit except that ours is signed and has a build qualifier.
- It also distinguishes fixed bundles. Some of our Orbit bundles fix badly produced metadata, in which case we want to ensure we don’t pick up the faulty bundles.
Brian.
|
