> -----Original Message----- > From: Enrique Rodriguez [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 06, 2005 9:49 AM > To: oscar-dev@incubator.apache.org > Subject: Status of maven plugins > > Hi, Felix list, > > I've had a couple problems pending with the Maven OSGi > Plugin, so I'm considering whether to jump to M2 and the > Felix M2 Plugin. >
Ah... The first potential user other than myself... ;) > I patched the Maven OSGi Plugin once before (I'm listed as a > contributor), but after emailing this week with the > developer, he can no longer maintain it. He is willing to > hand it over to us, but I wanted to check with you guys to > see if we're interested. I hope Brett will chime in, but his > opinion can be summarized as focusing on M2. > > So, what I'm wondering is: > > 1) Do we want to process the paperwork to pick up the Maven > OSGi Plugin? I don't think so, Brett says no ... anyone > really care to bring it here? Figured I'd ask. > If Apache owned the M1 codebase, then we could rob that codebase more readily in the development of the M2 plugin without having to get permission from the author. This has been on my TODO list anyway... Get permissions lined up from the berlios.de folks. Realizing that the M1 plugin codebase is written in Jelly and the M2 plugin codebase is written in Java, the *robbing* is more of a generalized how-to than straight up cutting&pasting. > 2) What features are currently supported by the Felix M2 > Plugin? What can I do to get some doco going? > I'm willing to document the current M2 functionality. Does Felix have a Confluence site? If not, I've got permissions over at the Safehaus Wiki, but it makes more sense for that documentation to be hosted here at Felix since we are hosting/developing the plugin. Someone just point me in the direction on how to document stuff like this at Felix, and I'll take care of it. As far as current functionality of the M2 plugin, I document the list here and respond to your specific requirements inline as well: (1) Can (optionally) specify a path/filename of a manifest.mf file in your project for the plugin to merge with the maven generated jar manifest. *Any* manifest entry is supported using this technique: osgi-standard or non-osgi-standard entries. (2) Can (optionally) specify individual attributes for OSGi manifest entries. I only have a subset of the standard OSGi manifest entries implemented so far (the ones that I've needed to date). Intention is to implement the full spec supported osgi manifest entries. (3) Can (optionally) use both (1) and (2) simultaneously. Both will be merged by the plugin. (4) Using the M2 <scope/> dependency attribute, the plugin may automatically bundle dependent jars into the root of generated osgi bundle. M2 dependencies that have scope of "provided" or "test" will NOT be bundled. M2 dependencies that have scope of "compile" or "runtime" WILL be bundled. M2 dependencies have a default scope of "compile". (5) If the plugin includes any dependent jars in the generated osgi bundle as a result of (4), then the Bundle-Classpath manifest entry WILL be automatically created and populated with path/filename(s) of the bundled dependencies. Therefore, inclusion of a Bundle-Classpath entry in either (1) or (2) is not necessary using the M2 plugin. (6) The Bundle-Version manifest entry is automatically populated based on the POM's artifact version attribute. Therefore, inclusion of a Bundle-Version entry in either (1) or (2) is not necessary using the M2 plugin. That's the current functionality off the top of my head without looking at the plugin code. Use of the plugin, as Maven users are well aware, revolves around dependencies being available at the either in your local M2 jar repo or (better still) at the M2 ibiblio repo. Widespread convenient use of the M2 plugin will require (at a minimum) the contribution of the osgi-framework, osgi-service, and osgi-util jars to M2 ibiblio repo. While these jars are typically provided by the Oscar/Felix instance at runtime, bundles will need compile time access to these jars. M2 makes it easy to add a jar to your local M2 repo, but they really need to be in the ibiblio remote repo. > Here's what I need that works in the Maven OSGi Plugin: > > a) Attributes based on POM: > Bundle-Vendor: > Bundle-DocURL: > Bundle-Version: > Bundle-Name: > Bundle-Description: > Bundle-Activator: > Bundle-Category: > Bundle-Classpath: > Export-Package: > Import-Package: > M2 plugin currently supports all of these attributes except Bundle-DocURL and Bundle-Category. Maybe add a issue to the FELIXM2 JIRA project? > b) Bundling of jar deps controlled by "osgi.jar.bundle" > property and their addition to the Bundle-Classpath, eg: > > <dependency> > <groupId>my-group</groupId> > <artifactId>my-artifact</artifactId> > <version>0.1-SNAPSHOT</version> > <properties> > <osgi.jar.bundle>true</osgi.jar.bundle> > </properties> > </dependency> > As noted in (4) above, the M2 currently supports this functionality via the M2 dependency <scope> attribute. M2 plugin will also automatically generate your Bundle-Classpath entry. > 3) Problems I'm stuck on with Maven OSGi Plugin: > > a) No support for custom manifest attribute required by > Service Binder: > Metadata-Location: path/to/metadata.xml > > If you try to add a custom attribute using standard maven jar > means, it doesn't work. For whatever reason, the > maven-osgi-plugin goals are "blocking" it. > M2 plugin currently supports this, as I have used the M2 plugin to "rebuild" all of RH's bundle tutorials at the Oscar still, which includes Service Binder tutorial. You use the M2's <resource> specifiers to actually include the metadata.xml file into the build, but the plugin supports the Metadata-Location attribute. You can use either method (1) or (2) to specify the Metadata-Location entry. > b) Correct detection of the Activator when implementation of > BundleActivator is sub-classed. This is also Service > Binder-related, since the implementation of BundleActivator > is in the GenericActivator and you extend that. > M2 plugin does have this support. Maybe add a issue to the FELIXM2 JIRA project? --tbennett
