Bundles Maven Plugin helps to build Bundles Archives to support the classloader isolation model. This is a fork/refactoring of the Apache Nifi Nar Maven Plugin, which aside from renaming, allows the configuration of the resulting 'bundle' name and extension. This way other systems can produce NARs/bundles and use the name they feel is appropriate.
- JDK 1.8 or higher
- Apache Maven 3.5.3 or higher
- Build with
mvn clean install
While it may be likely that a maven archetype is being utilized to create bundles, as part of a toolkit etc, you may want to create on manually, or may need to create a project for use in an archetype.
The plugin is utilized by setting the packaging of a maven module to 'bundle'.
<packaging>bundle</packaging>This means that when you package this module, any of it's non-provided dependencies will be packaged into the produced bundle ( and all of their non-provided dependencies as well). Since a library may not always be distributed as part of a bundle with all it's dependencies, the bundle module shall be a separate module from the actual classes and dependencies to be bundled.
A very simple example layout for a project that utilizes bundles would be:
├── README.md
├── pom.xml
├── testapp
│ ├── pom.xml
│ ├── src
│ │ ├── main
│ │ │ └── java
│ │ │ └── org
│ │ │ └── foo
│ │ │ └── test
│ │ │ └── App.java
│ │ └── test
│ │ └── java
│ │ └── org
│ │ └── foo
│ │ └── test
│ │ └── AppTest.java
└── testappbundle
├── pom.xmlWhere testappbundle is the bundle module that creates a bundle of testapp, and contains the following pom.xml:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>test.bundles.plugin</artifactId>
<groupId>org.foo.test</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>test.app.bundle</artifactId>
<!-- Packaging is bundle -->
<packaging>bundle</packaging>
<!-- All dependencies of this module, and all the dependencies of THAT dependency will
be included in the produced bundle -->
<dependencies>
<dependency>
<groupId>org.foo.test</groupId>
<artifactId>test.app</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
<build>
<!-- OUR PLUGIN REFERENCES -->
<pluginManagement>
<plugins>
<plugin>
<groupId>com.github.palindromicity</groupId>
<artifactId>bundles-maven-plugin</artifactId>
<version>0.1.0</version>
<extensions>true</extensions>
<configuration>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>com.github.palindromicity</groupId>
<artifactId>bundles-maven-plugin</artifactId>
<version>0.1.0</version>
<extensions>true</extensions>
</plugin>
</plugins>
</build>
</project>When the module is packaged, it packages all of it's non-provided dependencies into the bundles /bundled-dependencies directory. Thus, to create a bundle of a module's jar and that jar's non-provided dependencies, you add that module to your bundle modules dependencies. You can unzip and examine the bundle in the target directory, and verify it's contents, which should be similar to :
-> % tree .
.
└── META-INF
├── MANIFEST.MF
├── bundled-dependencies
│ ├── log4j-1.2.17.jar
│ ├── foo-common-0.0.1.jar
│ ├── slf4j-api-1.7.7.jar
│ ├── slf4j-log4j12-1.7.7.jar
│ └── test.app-1.0-SNAPSHOT.jar
└── maven
└── org.apache.test
└── test.app.bundle
├── pom.properties
└── pom.xmlThis reflects the testapp project, which has these dependencies :
<dependencies>
<dependency>
<groupId>org.foo</groupId>
<artifactId>foo-common</artifactId>
<version>0.0.1</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>foo-common itself is a shaded jar, but it depends on log4j and slf4j, so those libraries are pulled in..
- Create a new multi module maven project (if you do not have one already)
- Add a new module for your bundle, it needs only to have a pom.xml
- Create the pom.xml as above, with the correct plugin and packaging entries, and add dependencies for the module you want to bundle.
mvn package
There are several properties that can be set to change the behavior of this plugin. Two of special interest are:
packageType defines the type of archive to be produced and evaluated for special dependencies. The default packageType is bundle. This property should be changed if you have need to customize the file extension of archives produced by this plugin. This plugin will build archives with .bundle extentions, and look for othe .bundle dependencies by definition. Changing this value, for example to 'foo', will have the effect of having the plugin produce archives with .foo as the extension, and look for .foo files as bundle dependencies.
The archives produced by this plugin have the following entries added to the manifest ( where packageIDPrefix defaults to 'Bundle'):
- {packageIDPrefix}-Id
- {packageIDPrefix}-Group
- {packageIDPrefix}-Version
- {packageIDPrefix}-Dependency-Group
- {packageIDPrefix}-Dependency-Id
- {packageIDPrefix}-Dependency-Version
This property can be used to change the name of these manifest entries. One convention being to continue as the original by capitalizing the type, such as: Bundle to bundle
Except as otherwise noted this software is licensed under the Apache License, Version 2.0
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.