CodeQuirks

Introduction

Welcome to the second blog-post in the “Auto-Provisioning Features” series. For the first post, please Go Here

During this post I will be covering the improvements required to make our “features.xml” (or any XML artifact) automatically install, deploy, and release with Maven’s normal lifecycle. So let’s get right into it.

I’ll warn anyone who doesn’t like code, this post will mostly be XML simply because the Maven configurations are fairly self-explanatory.

mvn clean install

The simplest of our three goals is local install, so we’ll start there. If you recall from last time, we now have a template-based “features.xml” which represents the OSGi feature we would like to deploy to the customer. Now, since we would like to deploy using a Nexus repository, we need to make the XML artifact more Maven-friendly.

            <plugin>
                <artifactId>maven-install-plugin</artifactId>
                <executions>
                    <execution>
                        <phase>install</phase>
                        <configuration>
                            <groupId>${project.groupId}</groupId>
                            <artifactId>${project.artifactId}</artifactId>
                            <version>${project.version}</version>
                            <file>./target/classes/features-mvn.xml</file>
                            <generatePom>true</generatePom>
                            <packaging>xml</packaging>
                        </configuration>
                        <goals>
                            <goal>install-file</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

That’s all it takes.

All this will do is take the file, and do the equivalent of a “mvn install:install-file” using the POM’s  groupId, artifactId, and version. Because of that, it builds all of the versioning magic the pom has into the installation of the feature file.

I’ve also opted to have it generate its own pom. The pom we’re creating, while an effective tool, doesn’t do a great job of representing our features.xml for people browsing a Nexus repo.

mvn clean deploy

Now that installing works, we’ll jump straight to deploying. This takes a little bit more work, but is relatively reasonable.

First of all, let’s start by defining where we want to deploy to:

        <snapshotRepository>
            <id>snapshots</id>
            <name>Snapshots</name>
            <url>http://nexus/content/repositories/snapshots</url>
        </snapshotRepository>

Perfect. Next we’ll set up a property. This will be important as soon as we get to the “release” step later:

        <deployFileUrl>${project.distributionManagement.snapshotRepository.url}</deployFileUrl>

Now that we’ve got that working, we can do the last and most obvious step. This will look a lot like the install one:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-deploy-plugin</artifactId>
                <version>2.5</version>
                <configuration>
                    <skip>true</skip>
                </configuration>
                <executions>
                    <execution>
                        <phase>deploy</phase>
                        <configuration>
                            <url>${deployFileUrl}</url>
                            <groupId>${project.groupId}</groupId>
                            <artifactId>${project.artifactId}</artifactId>
                            <version>${project.version}</version>
                            <file>./target/classes/features-mvn.xml</file>
                            <generatePom>true</generatePom>
                            <packaging>xml</packaging>
                        </configuration>
                        <goals>
                            <goal>deploy-file</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

There’s very little to explain here. The only difference from “install” is the requirement for an url. Unfortunately, the plugin can’t pick up which url to deploy from the way a normal deploy does.

Also, we set the configuration for “skip” to be “true”. This tells Maven to skip deploying the normal set of artifacts and poms, and only deploy what’s described by our plugin invocation.

That covers how deployment works, so now we just need to release.

mvn release:prepare release:perform -P release-mode

The first thing you need to know about releasing using Maven is that the release plugin does push to a distribution management solution (Nexus, in our case). It, however, does this by doing the equivalent of a “mvn deploy” mid-way through the release process.

In our case, that means it will trigger the plugin we defined earlier, and end up committing the release version to the snapshot repository.

So first of all, let’s start by defining where we actually want the release repository to be:

        <repository>
            <id>releases</id>
            <name>Releases</name>
            <url>http://nexus/content/repositories/releases</url>
        </repository>

Next, we need to tell maven to use the repository. Remember the variable we set up earlier while doing “deploy”? Well it will come in handy now, because we’re going to override that variable using maven’s “profiles”:

    <profiles>
        <profile>
            <id>release-mode</id>
            <properties>
                <deployFileUrl>${project.distributionManagement.repository.url}</deployFileUrl>
            </properties>
        </profile>
    </profiles>

And of course, we need to tell Maven to use the release-mode profile during release:

            <plugin>
                <artifactId>maven-release-plugin</artifactId>
                <version>2.0</version>
                <configuration>
			<releaseProfiles>release-mode</releaseProfiles>
                </configuration>
            </plugin>

That’s it. Now, when releasing, Maven will do all if its magic, call the deploy plugin, and because we set up the profile correctly the release version of our features file will be deployed to our release nexus.

For the code used in this example, download Deployment.zip (via 2shared.com)