Auto-Provisioning OSGi Features: The Basics

Introduction

Welcome to the first blog post of my new tech blog. Unfortunately, the topic I chose was far larger than I anticipated, so this will actually consist of several blog-posts.

With each post, I will include a zip which shows how the example has evolved. If you want to skip straight to the zip, please scroll to the end of the post

In this series I will cover:

The Basics (Turning your “features.xml” into a feature template)
Deployment and Installation (Getting XML to your Nexus easily)
Automatic Versioning (The magic glue that makes this all automatic)

I will be assuming an understanding of Maven, and can include a later blog-post on the topic if viewers seem to want this.


Auto-Provisioning? What do you mean?

Recently, during a software project, we decided to deliver an application via OSGi inside a ServiceMix container. In order to do that, we chose to provision a “feature”, allowing the customer to install the entire application through a simple URL.

Doing so raised some interesting problems. How do you deploy a versioned “feature” file to a Nexus repository? And how do you automate the versioning of the bundles contained within it?

Our solution to that problem is the topic for this blog series. Feedback would be very appreciated.

(For more on provisioning features: http://servicemix.apache.org/kernel/46-provisioning.html)


The Basics

Turning your “features.xml” into a feature template

The process of creating a template features file is actually the most basic, and provides the least gain. However, it also lays the groundwork upon which the next two posts will build, so I will start there.

The first step is to simply create a “features” template. Place this in an appropriate templates directory, and format it to properly describe your feature. Use maven-style variables where relevant. For example:

    <?xml version="1.0" encoding="UTF-8"?>
    <!— Filename = /features/template/features-mvn.xml -->
    <features>
        <feature name="test-feature" version="${project.version}">
            <bundle>mvn:com.codequirks.test/bundle-one/${bundle-one.version}</bundle>
        </feature>
    </features>

Now the next step is of course, the basic pom settings:

    <?xml version="1.0" encoding="UTF-8"?>
    <project ... >
        <groupId>com.codequirks.test</groupId>
        <artifactId>features</artifactId>
        <version>1.0.0-SNAPSHOT</version>
        <packaging>pom</packaging>
        <name>Test Feature File</name>
        ...
    </project>

Of course, this is all the basics. Note the use of “pom” packaging, which means this thing does no compiling at all.

So the next goal is to get the Maven project to handle the template properly.

Step one, declare the version numbers as variables:

    <properties>
        <bundle-one.version>1.0.1</bundle-one.version>
    </properties>

Step two, declare the dependencies:

    <dependencies>
        <dependency>
            <groupId>com.codequirks.test</groupId>
            <artifactId>bundle-one</artifactId>
            <version>${bundle-one.version}</version>
        </dependency>
    </dependencies>

Now that we’ve set things up like this, maven can associate the variable with the appropriate dependency. Since all we’re doing is creating a template right now, this might seem pointless, but it will become very important later.

Lastly, let’s set up the plugin magic required to do the templating:

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <executions>
                    <execution>
                       <phase>process-resources</phase>
                        <goals>
                            <goal>resources</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
        <resources>
            <resource>
                <directory>./template</directory>
                <filtering>true</filtering>
                <targetPath>.</targetPath>
            </resource>
        </resources>
    </build>

Alright, so finally let’s give you the zip I promised. Here it is folks – the world’s most basic template!
Basics.zip (via 2shared.com)

Advertisements

2 comments on “Auto-Provisioning OSGi Features: The Basics

  1. Pingback: Auto-Provisioning OSGi Features: The Basics « Developing Code, Connecting Industry

  2. Pingback: Auto-Provisioning OSGi Features: Automatic Versioning « CodeQuirks

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s