In the project pom:
<build>
<plugins>
<plugin>
<groupId>com.springsource.bundlor</groupId>
<artifactId>com.springsource.bundlor.maven</artifactId>
<executions>
<execution>
<id>bundlor</id>
<!-- This isn't necessary, but Q4E barfs without it. -->
<phase>package</phase>
<goals>
<goal>transform</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
In the template (default location template.mf ) you put whatever hints and overrides you need to make bundlor behave (see Bundlor docos for details). Typically you will need a bundle version and symbolic name, and some patterns for imports (missing in the example):
Bundle-Name: Test App
Bundle-Version: ${project.version}
Bundle-SymbolicName: test.app
When the jar artifact is created (e.g. with mvn package ) a manifest is created from this template and placed in the jar file. It's contents depend on the bundle classes, and on the template. Here is a simple example:
Manifest-Version: 1.0 Bundle-Name: Test App Archiver-Version: Plexus Archiver Build-Jdk: 1.5.0_13 Built-By: dsyer Created-By: Apache Maven Bundle-ManifestVersion: 2 Bundle-SymbolicName: test.app Export-Package: test.app;version="1.0.0" Bundle-Version: 1.0.0
Placeholders (${...} ) in the template are handled by Bundlor, from a combination of Maven project properties and System properties (which take preference). The project properties are augmented with some well known values project.version, project.groupId, project.artifactId from the Maven POM (with synonyms project.* and version ).
All goals support configuration options for the location of the jar artifact and the template, e.g.
<build>
<plugins>
<plugin>
<groupId>com.springsource.bundlor</groupId>
<artifactId>com.springsource.bundlor.maven</artifactId>
<executions>
<execution>
<id>bundlor</id>
<phase>package</phase>
<goals>
<goal>transform</goal>
</goals>
<configuration>
<bundlePath>src/main/lib/test.jar</bundlePath>
<manifestTemplatePath>src/main/resources/META-INF/template.mf</manifestTemplatePath>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
The plugin will ignore any project that doesn't look like a bundle. This is controlled through the configuration of the packagings property (defaults to jar, bundle, war , e.g. to only convert jar artifacts use this
<build>
<plugins>
<plugin>
<groupId>com.springsource.bundlor</groupId>
<artifactId>com.springsource.bundlor.maven</artifactId>
<executions>
<execution>
<id>bundlor</id>
<phase>package</phase>
<goals>
<goal>transform</goal>
</goals>
<configuration>
<packagings>
<packaging>jar</packaging>
</packagings>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Individual projects can also be skipped by setting the configuration element enabled=false (defaults to true ).
You can also add overrides for manifest headers in the POM like this:
<build>
<plugins>
<plugin>
<groupId>com.springsource.bundlor</groupId>
<artifactId>com.springsource.bundlor.maven</artifactId>
<executions>
<execution>
<id>bundlor</id>
<phase>package</phase>
<goals>
<goal>transform</goal>
</goals>
<configuration>
<manifestHeaders><![CDATA[
Foo: Bar
SVN-Revision: ${svn.revision}
]]></manifestHeaders>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
N.B. Placeholders will be replaced in the manifestHeaders by Maven before the template is used, so unresolved placeholders will just show up as "null".
By default the plugin will fail if there are warnings from Bundlor. This behaviour can be changed by setting the value of the failOnWarnings flag in configuration.