...

If we also assume that we have a bundle activator in one of the implementation packages, then the <plugins> section of the POM file for this bundle project would look like this:

...
<plugins>
  <plugin>
    <groupId>org.apache.felix</groupId>
    <artifactId>maven-bundle-plugin</artifactId>
    <extensions>true</extensions>
    <configuration>
      <instructions>
        <Export-Package>org.foo.myproject.api</Export-Package>
        <Private-Package>org.foo.myproject.*</Private-Package>
        <Bundle-Activator>org.foo.myproject.impl1.Activator</Bundle-Activator>
      </instructions>
    </configuration>
  </plugin>
<plugins>
...

The <Export-Package> and <Private-Package> instructions tell the plugin about the contents of the resulting bundle JAR file. The <Export-Package> instruction tells the plugin which of the available packages to copy into the bundle and to export, while the <Private-Package> instruction indicates which of the available packages to copy into the bundle but not export. If the two sets overlap, as they do in the case, then the export takes precedence. Since we did not specify any values for any other bundle manifest headers, they will assume default values which are described below. One specific behavior to highlight is that the plugin generates the Import-Package bundle manifest header based on the specified contents of the bundle, which means that you generally do not ever need to explicitly specify it yourself. That's it.

Features

The BND library underlying the plugin defines instructions to direct its functionalitybehavior. For this Maven plugin, these instructions are issues issued in the plugin configuration section of the POM file, as was illustrated [above|#simple-example}. BND recognizes three types of instructions:

1. Manifest headers - Any instruction that starts with a capital letter will appear in the resulting bundle's manifest file; the value for the header will either be copied, augmented, or generated by BND depending on the instruction.
2. Variables - Any instruction starting with a lowercase letter is assumed to be a variable in the form of a name-value pair, such as version=3.0, that can be used with for property substitution, but are is not copied to the manifest.
3. Directives - Any instruction starting with a '-' character is considered to be a directive that informs BND to perform some special processing and are is not copied to the manifest.

...

Instructions

<Export-Package>

The <Export-Package> instruction is a list of packages for the bundle to export. These packages are copied into the resulting bundle JAR file from the available classes (i.e., project classes, dependencies, and class path); thus, your it is possible to include classes into your bundle that are not associated with source files in your project. <Export-Package> can be specified with package patterns using the '*' wildcard. Also, it is possible to exclude packages with using negation by starting the package pattern with '!'. Thus, non-negated patterns indicate which of the available packages to include in the bundle, whereas negated patterns indicate which should not be included in the bundle.

...

Following standard OSGi R4 syntax, package patterns can include both directives and attributes, which will be copied appropriately into the generated Export-Package manifest header. The version of packages is determined Besides explicitly listing package version attributes, BND will also determine package versions by examining the source JAR file or from packageinfo files in the package directory.

<Private-Package>

The <Private-Package> instruction is similary similar in every way to the <Export-Package> instruction, except for the fact that these packages will not be exported by the bundle. If a package is selected by both the export and private package headers, then the export takes precedence.

<Include-Resource>

The <Include-Resource> instruction is a list of arbitrary resources that should be copied into the bundle JAR file. The specified resources are declared as clauses that can have the following forms:

...

For the <Include-Resource> instruction, actual file paths are relative to the pom.xml, while file copies copy destinations are relative to the root of the resulting bundle JAR file. In the case of assignment or simple forms, the PATH parameter can point to a file or directory. The simple form will place the resource in the bundle JAR with only the file name, i.e., without any path component. For example, including src/main/resources/a/b.c will result in a resource b.c in the root of the bundle JAR. If the PATH points to a directory, the entire directory hierarchy is copied into the resulting bundle JAR file relative to the specified directory. If a specific resource must be placed in into a subdirectory of the bundle jar, then use the assignment form, where the first path is the resource to copy and the second path is the destination path (including file name). The inline form requires a ZIP or JAR file, which will be completely expanded in the bundle JAR.

If a resource clause is specified inside of "{ ... }" brackets, then variable substitution will be performed on the resource, where variables in the resources are denoted with "${ ... }" syntax.

<Import-Package>

The <Import-Package> instruction is a list of packages that are required by the bundle's contained packages. The default for this header is "*", resulting in importing all referred packages. This header therefore rarely has to be explicitly specified. However, in certain cases when there is an unwanted import, such an import can be removed by using a negation package pattern. The package patterns work in the same way as for <Export-Package>, which means they are ordered. For example, if you wanted to import all packages except org.foo.impl you would specify "!org.foo.impl,*"

...

To use this plugin, very little information is required by BND. As part of the Maven integration, the plugin tries to set reasonable defaults for various instructions. For example:

• <Bundle-SymbolicName> is assumed to be "${groupId}.${artifactId}".
• <Export-Package> is assumed to be "${groupId}.${artifactId}.*", unless <Private-Package> is specified, then <Export-Package> is assumed to be empty.
• <Private-Package> is assumed to be empty by default.
• <Import-Package> is assumed to be "*", which imports everything else not referred to by the bundle content, but not contained in the bundle.
• <Include-Resource> is assumed to be "src/main/resources/", which will copy the specified project directory hierarchy into the resulting bundle JAR file, mirroring standard Maven behavior.
• <Bundle-Version> is assumed to be "${pom.version}" with '-' characters character separator of the qualifier replaced with a '.' characterscharacter.
• <Bundle-Name> is assumed to be "${pom.name}".
• <Bundle-Description> is assumed to be "${pom.description}".
• <Bundle-License> is assumed to be "${pom.licenses}".
• <Bundle-Vendor> is assumed to be "${pom.organization}".

...

1. Using the SVN client of your choice, checkout the Maven 2 OSGi maven-bundle-plugin project.

$ svn co http://svn.apache.org/repos/asf/incubator/felix/trunk/tools/maven2/maven-bundle-plugin

1. Using Maven2, build and install the maven-bundle-plugin by issuing the following Maven2 command in the project directory that was created as a result of step 1.

$ mvn install

Using the

...

Plugin

To use the maven-osgibundle-plugin, you first need to add the plugin and some appropriate plugin configuration to your bundle project's POM. Below is an example of a simple OSGi bundle POM for Maven 2Maven2:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>my-osgi-bundles</groupId>
  <artifactId>examplebundle</artifactId>
  <packaging>bundle</packaging>    <!-- (1) -->
  <version>1.0</version>
  <name>Example Bundle</name>
  <build>
    <plugins>
      <plugin>    <!-- (2) START -->
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <Export-Package>com.my.company.api</Export-Package>
            <Private-Package>com.my.company.*</Private-Package>
            <Bundle-Activator>com.my.company.Activator</Bundle-Activator>
          </instructions>
        </configuration>
      </plugin>    <!-- (2) END -->
    </plugins>
  </build>
  <dependencies>
    <dependency>
      <groupId>org.apache.felix</groupId>
      <artifactId>org.osgi.core</artifactId>
    </dependency>
  </dependencies>
</project>

Two main things to note: (1) the <packaging> specifier must be "bundle" and (2) the plugin and configuration specification .there is no need to embed the dependent jar into the bundle archivemust specified (the configuration section is where you will issue instructions to the plugin).

Real-World Example

Consider this more real-world example using Felix' Log Service implementation. The Log Service project is comprised of a single package: org.apache.felix.log.impl. It has a dependency on the core OSGi interfaces as well as a dependency on the compendium OSGi interfaces for the specific log service interfaces. The following is its POM file:

...