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:19:19 GMT
On Tue, Oct 28, 2008 at 3:29 AM, Pierre-Arnaud Marcelot <>wrote:

> Hi Chris,
> 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.
> Recently, we've had the same problematic on Studio.
> As you know Eclipse plugins are based on OSGI bundles which makes the
> 'META-INF/MANIFEST.MF' file a very important file.
> We wanted to remove this file (because it was causing some problems when
> releasing) and have it generated by Maven at build time.
> To do so we've used the Felix Bundle plugin. I don't know if you know this
> one but it's life savior when dealing with OSGI bundles.

I am definitely using this plugin  ;-)  I couldn't imagine doing it any
other way these days.

> 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.
> We have the same "issue" (if we can call that an issue) in Studio...
> Sometimes some plugins, the 3 plugins of the LDAP Browser for example,
> contribute classes to the same package.
> For us, it's not such a big deal. The only need we had to do is provide the
> correct configuration for the Felix Bundle plugin in terms of imported and
> exported packages.
>> 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.
> Re-organizing packages to have more unique structure is also my personal
> preference and it implicates some important refactoring. But for sure, this
> would help a lot when reviewing code. Sometimes it takes me some time to
> find where a specific class is hidden in the various projects.
> The idea of consolidated jar files is something that can be acheived more
> easily. Actually, we already have an "apacheds-all" artifact that should
> contain all the ApacheDS code.

Thanks for reminding me about apacheds-all!!  I had completely forgotten
about it so i will try to use that for now and this will help make things
easier.  I was already starting to build a large single bundle, but this
will be better.


> Hope this helps,
> Pierre-Arnaud Marcelot

View raw message