For the time being, thanks to Pierre-Arnaud I am going to use apacheds-all to build a single large bundle that is suitable for embedding standard directory functionality in an OSGi container. This will simplify things and help focus on the task of just getting things to work inside an OSGi container.
For a long term solution where we might choose to ship ApacheDS as a complete OSGi based solution, we will still want to consolidate some of the split packages into single jar files or selectively rename some of the packages to be more unique. I will follow up with more detailed proposals on that in the next week.
My Blog :: http://blog.organicelement.com
Apache ServiceMix :: http://servicemix.apache.org
Apache Directory Server :: http://directory.apache.org
David Jencks wrote:Here are the projects which are sharing the same package :
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.
apacheds/core & apacheds/xdbm-base
apacheds/core & apacheds/jdbm-store
apacheds/core-shared, apacheds/schema-bootstrap & apacheds/schema-extras
There is not so much we can do with the last example, as this code is pretty generic, and _must_ be in the same package, even if not in the same project. However, they are closely related. For the two previous cases, core, xdbm-base and jdbm-store are also closely related.
I don't know how possibly I can help with this issue, except that I think they should be delivered as a single OSGi assembly, as it does not make sense to load core without loading at the same time jdbm-store and xdbm-base.
My guess (but I know nothing about OSGi), is that Guillaume is close to the best possible solution : consider the project not as an assembly of 50 small elements, but as 4 or 5 projects (apacheds, shared, protocol-XXX, etc)
I don't know if it helps ...
PS : I extracted those info with grep, sed, and OpenOffice spreadsheet.