On Tue, Oct 28, 2008 at 3:29 AM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrote:
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.

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 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.

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