Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
xml
xml
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
  <obrRepository>PATH_TO_OBR</obrRepository>
  <instructions>
    <!-- bnd instructions -->
  </instructions>
</configuration>

...

Code Block
xml
xml
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
  <obrRepository>NONE</obrRepository>
  <instructions>
    <!-- bnd instructions -->
  </instructions>
</configuration>

...

to create the appropriate Eclipse files and manifest, and also handle any embedded entries. The pax:eclipse goal extends eclipse:eclipse, and supports the same parameters.

Unpacking bundle contents to 'target/classes'

Once in a while you may create a bundle which contains additional classes to the ones compiled from src/main/java, for example when you embed the classes from another jar. This can sometimes cause unforeseen problems in Maven, as it will use the output directory (target/classes) rather than the final bundle, when compiling against projects in the same reactor (ie. the same build).

The easiest way to get around this Maven 'feature' is to unpack the contents of the bundle to the output directory after the packaging step, so the additional classes will be found where Maven expects them. Thankfully there is now an easy option to do this in the bundle-plugin:

Code Block

<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
  <unpackBundle>true</unpackBundle>
  <instructions>
    <!-- bnd instructions -->
  </instructions>
</configuration>

Using an existing MANIFEST.MF file

...