On Tue, Oct 28, 2008 at 3:29 AM, Pierre-Arnaud Marcelot <[EMAIL PROTECTED]>wrote:
> Hi Chris, > > On Mon, Oct 27, 2008 at 9:15 PM, Chris Custine <[EMAIL PROTECTED]>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. Thanks, Chris > > Hope this helps, > Pierre-Arnaud Marcelot >
