directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet" <>
Subject Re: OSGi Packaging for ApacheDS
Date Mon, 27 Oct 2008 20:50:40 GMT
The other alternative may be to create a single bundle which contains
all the apacheds classes without the third party dependencies.
CXF hit the same problem and they have included this big bundle into
their build process so that users can still deploy it in OSGi.  Such a
jar can also be used when embedding ApacheDS and can be used by
non-OSGi users too as it avoids dealing with all the small jars.
I guess, in the short term, this may be the easiest way, pending a
reorganization of the packages.
My 2 cents.

On Mon, Oct 27, 2008 at 9: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?
> Thanks,
> Chris
> --
> Chris Custine
> My Blog ::
> Apache ServiceMix ::
> Apache Directory Server ::

Guillaume Nodet
Open Source SOA

View raw message