directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre-Arnaud Marcelot" ...@marcelot.net>
Subject Re: OSGi Packaging for ApacheDS
Date Tue, 28 Oct 2008 09:29:34 GMT
Hi Chris,

On Mon, Oct 27, 2008 at 9:15 PM, Chris Custine <ccustine@apache.org> 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.


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.


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.

Hope this helps,
Pierre-Arnaud Marcelot

Mime
View raw message