directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Custine" <>
Subject Re: OSGi Packaging for ApacheDS
Date Tue, 28 Oct 2008 15:27:30 GMT
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

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.


Chris Custine
My Blog ::
Apache ServiceMix ::
Apache Directory Server ::

On Mon, Oct 27, 2008 at 5:09 PM, Emmanuel Lecharny <>wrote:

> 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
> org/apache/directory/server/core/partition/impl/btree
> apacheds/core & apacheds/jdbm-store
> are sharing
> org/apache/directory/server/core/partition/impl/btree/jdbm
> apacheds/core-shared, apacheds/schema-bootstrap & apacheds/schema-extras
> are sharing
> org/apache/directory/server/schema/bootstrap
> 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.
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message