I am interested in the bundlor tool; I don't yet know much about the Virgo project as a whole. My first question is the extent to which the eclipse team plans to support this tool in the future. It seems a bit hidden in the Virgo project web page (though I did get a downloaded copy somewhere).
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.
My second question is about importing exported packages. This appears to be good OSGi practice (http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html for example
) and it has helped me on occasion from getting separate versions of the same class in an OSGi framework instance. However I didn't figure out how to make this happen. In addition there is place in the bundlor-1.1.0.M03 documentation that suggests that bundlor regards importing exports as an error:
Bundlor checks that the manifest does not import any package that it exports. This behavior is usually indicative of a package split between two bundles.
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.
My final question is whether you would consider adding some newlines to the generated manifest to make it a bit easier to read. In particular, I believe that you don't need to wait for character 72 to use a newline and a space in a manifest. If this is correct then I think it would be useful if the manifest was just a bit easier to read (it isn't worth working too hard on this). I admit that the manifest is a generated file but sometimes when debugging the manifest it would be nice to read it a bit more easily.
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.)