You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Carsten Ziegeler <cz...@apache.org> on 2008/01/08 21:53:36 UTC
Problems with bundle plugin [Fwd: Re: Support for OSGi]
Forwarding to the Felix list.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Problems with bundle plugin [Fwd: Re: Support for OSGi]
Posted by Stuart McCulloch <st...@jayway.net>.
On 09/01/2008, Carsten Ziegeler <cz...@apache.org> wrote:
>
> Forwarding to the Felix list.
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>
> On Dec 28, 2007 12:35 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> > Hi,
> >
> > in the meantime Stuart fixed the problem with the maven bundleplugin, so
> > I think we can give it a test drive :)
> >
> > Attached is a patch for the parent pom of commons and one to demonstrate
> > how to add support for OSGi to commons-lang.
> >
> > The changes to the parent pom are minimal: it just adds the maven
> > bundleplugin from the Apache Felix project. We currently need to use a
> > snapshot version, but a release is comming soon.
> > Besides adding the plugin, the patch also configures the bundle symbolic
> > name for all modules. The symbolic name is the unique identifier which
> > should follow java package naming. The best value is to use something
> > like "org.apache.commons.{artifactId}" where artifact id is commons-lang
> > or commons-collections etc.
> >
> > The patch to commons lang is also very simple. It changes the parent pom
> > to the current snapshot (which includes the changes from above) and sets
> > the packaging to bundle - this ensures that the bundleplugin runs and
> > creates the resulting jar file. So the bundleplugin replaces the maven
> > jar plugin. If you leave the packaging as "jar" the bundleplugin will
> > not run.
> > The last part of the patch adds the configuration to the bundleplugin.
> > The export "*" exports all packages definied in this module for other
> > bundles, so all classes are public. All packages are marked with the
> > current version which allows to run different versions in parallel.
> > The imports are not specified as they are calculated automatically by
> > the bundleplugin.
> >
> > And that's it :)
> >
> > The changes to the other projects should be similar.
>
> I tried using the bundle plugin (I checked out and built the latest
> from svn) with Commons Validator and it produced the following
> MANIFEST.MF:
>
> http://people.apache.org/~niallp/commons-osgi/commons-validator-MANIFEST.MF
>
> It seems to have picked up some Manifest entries from BeanUtils - for
> example:
>
> Extension-Name: org.apache.commons.beanutils
> Implementation-Version: 1.6
> Specification-Title: Jakarta Commons Beanutils
> Implementation-Title: org.apache.commons.beanutils
yes, I believe it's because you used:
<Export-Package>*;version=${pom.version}</Export-Package>
which instructs the Bnd tool to include _everything_ from the project's
Maven classpath
- this will include all metadata and classes from any compile or runtime
dependencies,
in this case BeanUtils metadata (you'll probably see BeanUtils classes in
the jar)
<background>
The Bnd tool accepts a classpath and set of instructions, and uses these to
pull classes
and resources into the final bundle. This makes Bnd very flexible, because
you can use it
to separate the same project classpath into different bundles just by
supplying different
instructions.
The three key instructions that pull in content are Export-Package,
Private-Package and
Include-Resource. Because Bnd doesn't know about Maven dependencies or
resources
(it can also be used with Ant and Eclipse) we do various translations in the
bundleplugin
such as adding Include-Resource entries for resource directories, and
changing our local
Embed-Dependency instructions into the real Bnd instructions needed to embed
jarfiles.
</background>
Anyway, back to the issue - normally we'd expect users to set an explicit
Export-Package,
not use the global export wildcard. For commons-validator I would expect
something like:
<Export-Package>org.apache.commons.validator.*;version=${pom.version
}</Export-Package>
However, to smooth the transition for commons projects we could add a
bundleplugin option
to exclude dependencies from the classpath passed to Bnd - that would mean
you could use
<Export-Package>*</Export-Package> without dragging in your dependencies.
NOTE: this won't be the default setting, because several users rely on the
current behaviour,
which is useful when assembling a single bundle from a number of
dependencies.
I've raised an issue to track this:
http://issues.apache.org/jira/browse/FELIX-449
Niall
>
> (N.B. The BeanUtils 1.7.0 jar has version incorectly specifying 1.6 in
> its manifest.
>
> > Carsten
> >
> >
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
> >
> > Index:
> /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml
> > ===================================================================
> > ---
> /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml
> (revision 605909)
> > +++
> /Users/cziegeler/Developer/workspaces/default/commons-proper/commons-parent/pom.xml
> (working copy)
> > @@ -159,6 +159,12 @@
> > <artifactId>maven-release-plugin</artifactId>
> > <version>2.0-beta-7</version>
> > </plugin>
> > + <plugin>
> > + <groupId>org.apache.felix</groupId>
> > + <artifactId>maven-bundle-plugin</artifactId>
> > + <version>1.1.0-SNAPSHOT</version>
> > + <inherited>true</inherited>
> > + </plugin>
> > </plugins>
> > </pluginManagement>
> > <plugins>
> > @@ -194,6 +200,15 @@
> > <jdkLevel>${maven.compile.source}</jdkLevel>
> > </configuration>
> > </plugin>
> > + <plugin>
> > + <groupId>org.apache.felix</groupId>
> > + <artifactId>maven-bundle-plugin</artifactId>
> > + <configuration>
> > + <instructions>
> > + <Bundle-SymbolicName>org.apache.commons.${pom.artifactId}
> </Bundle-SymbolicName>
> > + </instructions>
> > + </configuration>
> > + </plugin>
> > </plugins>
> > </build>
> >
> >
> > Index:
> /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml
> > ===================================================================
> > ---
> /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml
> (revision 605909)
> > +++
> /Users/cziegeler/Developer/workspaces/default/commons-proper/lang/pom.xml
> (working copy)
> > @@ -22,13 +22,14 @@
> > <parent>
> > <groupId>org.apache.commons</groupId>
> > <artifactId>commons-parent</artifactId>
> > - <version>5</version>
> > + <version>6-SNAPSHOT</version>
> > </parent>
> > <modelVersion>4.0.0</modelVersion>
> > <groupId>commons-lang</groupId>
> > <artifactId>commons-lang</artifactId>
> > <version>2.4-SNAPSHOT</version>
> > <name>Commons Lang</name>
> > + <packaging>bundle</packaging>
> >
> > <inceptionYear>2001</inceptionYear>
> > <description>
> > @@ -401,6 +402,16 @@
> > <tarLongFileMode>gnu</tarLongFileMode>
> > </configuration>
> > </plugin>
> > + <plugin>
> > + <groupId>org.apache.felix</groupId>
> > + <artifactId>maven-bundle-plugin</artifactId>
> > + <extensions>true</extensions>
> > + <configuration>
> > + <instructions>
> > + <Export-Package>*;version=${pom.version}</Export-Package>
> > + </instructions>
> > + </configuration>
> > + </plugin>
> > </plugins>
> > </build>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
--
Cheers, Stuart