directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: OSGi Packaging for ApacheDS
Date Mon, 27 Oct 2008 23:09:41 GMT
David Jencks wrote:
> On Oct 27, 2008, at 1:15 PM, Chris Custine wrote:
>> Hi Guys,
>> 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 
>>* 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.
Here are the projects which are sharing the same package :

apacheds/core & apacheds/xdbm-base
are sharing

apacheds/core & apacheds/jdbm-store
are sharing

apacheds/core-shared, apacheds/schema-bootstrap & apacheds/schema-extras
are sharing

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 

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.

cordialement, regards,
Emmanuel L├ęcharny

View raw message