|Re: [virgo-dev] plans for the bundlor toolset|
On 6 Jan 2012, at 18:43, Timothy Redmond wrote:
We want to maintain bundlor as part of Virgo, but given that the SpringSource bundlor is pretty stable and bug free, we haven't paid much attention to Virgo bundlor. For instance, we haven't gone through the Eclipse release process for Virgo bundlor.
The recommendation to import exported packages is not as clear cut as you might think:
1. The above blog was tweaked in January 2010 to add some caveats.
2. I believe the only generally valid usecase is where a bundle exports a package containing one or more interfaces but *no* implementation classes. In that case, it might make sense to import the package too so that the bundle could share the package with another bundle which exports the package.
3. The practice derives from OSGi R3 behaviour which didn't have version ranges on imports and made the generally false assumption that higher versions of packages are always backward compatible with lower versions.
4. There are still situations being discussed in the OSGi Expert Groups where so called "substitutable exports" don't make sense. E.g. when the imported version range excludes the exported version (!).
However, Bundlor was designed with enterprise use cases in mind. In this case, we didn't want to encourage people to have multiple bundles in a system exporting an interface package as that would probably cause confusion.
But I accept that there may be rare situations in which Bundlor should allow this practice and we could perhaps change Bundlor's behaviour, e.g. via a switch or by some indication in the manifest template. Alternatively, users with this requirement are free to use bnd instead.
That seems like a reasonable enhancement. Perhaps you would care to raise an enhancement bugzilla. I can't commit any resources to it at the moment, but it's the sort of thing that even a newcomer could take a crack at. (Feel free to have a go yourself - if you hit problems, we can help you.)