The Maven Launchpad Plugin provides goals which facilitate the creation of OSGi applications. It supports the following runtime scenarios:
- A WAR file suitable for running in a JavaEE servlet container.
- A standalone Java application, with HTTP support from the Felix HttpService implementation
- Inside Apache Karaf
In addition, the Maven Launchpad Plugin supports the publishing of an application descriptor, in the form of a bundle list, as a Maven artifact. This descriptor can then be used by downstream application builders as the basis for other applications. In Sling, this is embodied by two Maven projects:
- org.apache.sling.launchpad - produces an application descriptor.
- org.apache.sling.launchpad.testing - uses the application descriptor from org.apache.sling.launchpad and adds two bundles.
Maven Launchpad Plugin provides the following goals:
|launchpad:prepare-package||Create the file system structure required by Sling's Launchpad framework.|
|launchpad:attach-bundle-list||Attach the bundle list descriptor to the current project as a Maven artifact.|
|launchpad:create-karaf-descriptor||Create an Apache Karaf Feature descriptor.|
|launchpad:create-bundle-jar||Create a JAR file containing the bundles in a Launchpad-structured JAR file.|
|launchpad:check-bundle-list-for-snapshots||Validate that the bundle list does not contain any SNAPSHOT versions.|
|launchpad:run||Run a Launchpad application.|
|launchpad:start||Start a Launchpad application.|
|launchpad:stop||Stop a Launchpad application.|
|launchpad:output-bundle-list||Output the bundle list to the console as XML. (added in version 2.0.8)|
In general, the bulk of the configuration of the Maven Launchpad Plugin is concerned with setting up the bundle list which all of the goals will use. This bundle list is created using the following steps:
- If includeDefaultBundles is true (the default), the default bundle list is loaded. By default, this is org.apache.sling.launchpad:org.apache.sling.launchpad:RELEASE:xml:bundlelist, but can be overridden by setting the defaultBundleList plugin parameter.
- If includeDefaultBundles is false, an empty list is created.
- If the bundle list file exists (by default, at src/main/bundles/list.xml), the bundles defined in it are added to the bundle list.
- If the additionalBundles plugin parameter is defined, those bundles are added to the bundle list.
- If the bundleExclusions plugin parameter is defined, those bundles are removed from the bundle list.
When a bundle is added to the bundle list, if a bundle with the same groupId, artifactId, type, and classifier is already in the bundle list, the version of the existing bundle is modified. However, the start level of a bundle is never changed once that bundle is added to the bundle list.
The plugin may also contribute bundles to (or remove bundles from) the bundle list as it sees fit.
For the run and start goals, the plugin will look for a file named src/test/config/sling.properties. If this file is present, it will be filtered using standard Maven filtering and used to populate the OSGi framework properties. This can be used, for example, to specify a repository.xml file to be used during development:
The bundle list file uses a simple XML syntax representing a list of bundles organized into start levels:
Within each bundle element, type and classifier are also supported.
The defaultBundleList, jarWebSupport, additionalBundles, and bundleExclusions parameters are configured with artifact definitions. This is done using a syntax similar to Maven dependency elements:
For example, to use Pax Web instead of Felix HttpService as the HttpService provider, use the following:
In the case of additionalBundles and bundleExclusions, these are arrays of definitions, so an intermediate bundle element is necessary:
By default, bundles are added to start level 0. To change, this use the startLevel element within each additional bundle definition.
For integration testing examples, see /samples/inplace-integration-test and launchpad/testing in the Sling source tree.
The Maven Launchpad Plugin supports the use of rules to rewrite the bundle list. These rules are executed by the Drools rule engine. Typically, this is used along with Maven profiles. For example, Sling's testing project includes a profile called test-reactor-sling-bundles. When activated, this profile runs a Drools rule file which scans the project list from the Maven reactor and modifies the version number for bundles which were contained within the reactor.
In order for rules to interact with the Maven build, the following global variables are made available:
- mavenSession - an instance of org.apache.maven.execution.MavenSession.
- mavenProject - an instance of org.apache.maven.project.MavenProject.