On Oct 27, 2008, at 1:15 PM, Chris Custine wrote:
As an interim step to eventually deploying inside an OSGi container, I have started working out packaging the jar files as OSGi bundles just to see how much work it will be. The idea is that in the short term nothing should affect ongoing development because the bundle packaging is just some modifications to the module pom.xml files which add the OSGi headers to the MANIFEST.MF files at build time.
In doing this I have realized that there are quite a few cases of split packages where two (sometimes three or more) projects have classes in the same package. This is important for the OSGi packaging because package names are the primary descriptor for importing and exporting code from bundles and if more than one bundle exports from the same package there is quite a bit more work to maintaining the packaging configuration (in this case, a plugin config in the pom.xml). One big example is the org.apache.directory.server.core.partition.* packages which are contained in multiple partition implementations as well as apacheds-core.
So my first question is if this is something that we want to discuss and start taking care of now? There are several solutions obviously, and it is quite possible that we can work around this with hand crafted packaging descriptors for the OSGi bundles. This is a bit of work however and long term maintenance of the packaging will be much higher. Other options include re-organizing packages to have more unique structure (my personal preference), or we could also combine some of the scattered code into consolidated jar files.
Any input or alternative ideas?
IMO fixing this so that all classes from a package are in the same jar is the way to go, and sooner is better. I think that looking carefully at what is misplaced will be needed to determine if changing the package name or moving the class is a better solution.
Do you have a tool to identify this kind of problem? I suspect geronimo might have similar issues.