Over a million developers have joined DZone.

Assemble Your Custom Apache Karaf with the Karaf-Maven-Plugin

DZone's Guide to

Assemble Your Custom Apache Karaf with the Karaf-Maven-Plugin

Free Resource

Share, secure, distribute, control, and monetize your APIs with the platform built with performance, time-to-value, and growth in mind. Free 90-day trial of 3Scale by Red Hat

I was quite happy to find out there is a Maven Plugin with which you can assembly a full Apache Karaf and include your own features/bundles.

From time to time I like to test my bundles in a real environment. Because of that the plugin is a great way to save the steps of unzipping a new Karaf, adding my feature and installing it.

So the plugin basically serves my laziness.

But before the lazy part starts (for me and you) we have to do some work to get the plugin running.

I will start to describe the things I figured out. Then I will show you my final configuration and at the end I will talk about the problems I encountered.

Of course you can take a look at the documentation (here and here), too.


To start your assembly project you just need an empty maven project with the packaging "karaf-assembly" and the plugin, of course.

To configure the features for the plugin (so the features will end up in the Karaf) there are three options:

  1. startupFeature
  2. bootFeature
  3. installedFeature

Here is an example:

1. <configuration>
2.   <bootFeatures>
3.     <feature>standard</feature>
4.     <feature>management</feature>
5.     <feature>camunda-bpm-karaf-feature-minimal</feature>
6.   </bootFeatures>
7. </configuration>

All three types result in a different configuration. Since I don't want to copy the documentation I'll give a very brief explanation.


All the bundles from your feature will appear in the startup.properties, copied to system/ and started with the Karaf.


All the bundles from your feature will be copied to system/. The features you listed will appear in org.apache.karaf.features.cfg and installed when starting Karaf. The path to your feature.xml will be added to org.apache.karaf.features.cfg as feature repository.


All the bundles from your feature will be copied to system/. The path to your feature.xml will be added to org.apache.karaf.features.cfg as feature repository.

You can see that every kind of *Features gets a little bit less serious than the one before. Please note that "compile" dependencies in your POM will be treated like a startupFeature.

All the dependencies you want to include have to be ether of type "kar" or have to have the classifier "feature" and type "xml", e.g:

1. <dependency>
2.   <groupId>org.apache.karaf.features</groupId>
3.   <artifactId>standard</artifactId>
4.   <version>3.0.2</version>
5.   <classifier>features</classifier>
6.   <type>xml</type>
7.   <scope>runtime</scope>
8. </dependency>

Other dependencies will be ignored.

That was all I could figure out about the configuration of the plugin. Now let's have a look at my project.

My project

As mentioned before my project contains no classes or anything under src/resources. It just has the pom.xml that looks like this (Github link).

I added a small shell script because the karaf start file wasn't executable and because I didn't want to move to target/assembly/... every time. Also I had a small problem with Java (see following heading).

The script looks like this:

1. chmod777 ./target/assembly/bin/karaf
2. ./target/assembly/bin/karaf start

Nothing fancy ;-) So, that's already all about my project. Finally, I want to tell you about the problems I faced.


Plugin version

I had the problem that when a feature contained nested features the nested ones wouldn't be resolved. It took me a while and some remote debugging to find the problem. After I asked in the mailing list I was told that the problem existed in my version (3.0.1) and is fixed in the next one.

So you should definitely use the 3.0.2-SNAPSHOT version despite the fact that it's a snapshot. Jean-Baptiste did some great improvements in that version. The logging is way better and you can have nested features.

Ordering of dependencies

After upgrading my version I could see that all of my bundles were successfully installed into the system/ directory. But after starting my Karaf they weren't deployed. The "mvn:" URL for my feature was missing in the org.apache.karaf.features.cfg "featuresRepositories" property.

I found out that the problem was in the order of my dependencies.

My feature was the first dependency and then followed the Apache Karaf dependencies. Like this:

01. <dependencies>
02.   <dependency>
03.     <groupId>org.camunda.bpm.extension.osgi</groupId>
04.     <artifactId>camunda-bpm-karaf-feature</artifactId>
05.     <version>1.1.0-SNAPSHOT</version>
06.     <classifier>features</classifier>
07.     <type>xml</type>
08.     <scope>runtime</scope>
09.   </dependency>
10.   <dependency>
11.     <groupId>org.apache.karaf.features</groupId>
12.     <artifactId>framework</artifactId>
13.     <version>3.0.2-SNAPSHOT</version>
14.     <type>kar</type>
15.   </dependency>
16.   <dependency>
17.     <groupId>org.apache.karaf.features</groupId>
18.     <artifactId>standard</artifactId>
19.     <version>3.0.2-SNAPSHOT</version>
20.     <classifier>features</classifier>
21.     <type>xml</type>
22.     <scope>runtime</scope>
23.   </dependency>
24. </dependencies>

The problem is that the framework Kar contains all the configuration files. So when the plugin tries to update the config-file with my feature it is not present. So be careful that the framework kar is your first dependency.

That was all about my karaf-maven-plugin experience. I am sure there are some more hidden things I couldn't figure out. I hope my experience will be useful for someone else.

Have fun with your own custom Karaf!

Explore the core elements of owning an API strategy and best practices for effective API programs. Download the API Owner's Manual, brought to you by 3Scale by Red Hat

java ,opinion ,enterprise-integration ,integration ,apache maven ,apache karaf

Published at DZone with permission of Ronny Bräunlich, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}