Maven Release to Nexus

1. Overview

In the previous article of this series, we set up a deployment process with Maven to Nexus. In this article, we’ll configure the Release Process with Maven – both in the pom of the project as well as in a Jenkins job.

2. Repository in the pom

In order for Maven to be able to release to a Nexus Repository Server, we need to define the repository information via the distributionManagement element:

<distributionManagement>
   <repository>
      <id>nexus-releases</id>
      <url>http://localhost:8081/nexus/content/repositories/releases</url>
   </repository>
</distributionManagement>

The hosted Releases Repository comes out of the box on Nexus, so there is no need to create it explicitly.

3. SCM in the Maven pom

The Release process will interact with the Source Control of the project – this means we first need to define the <scm> element in our pom.xml:

<scm>
   <connection>scm:git:https://github.com/user/project.git</connection>
   <url>http://github.com/user/project</url>
   <developerConnection>scm:git:https://github.com/user/project.git</developerConnection>
</scm>

Or, using the git protocol:

<scm>
   <connection>scm:git:[email protected]:user/project.git</connection>
   <url>scm:git:[email protected]:user/project.git</url>
   <developerConnection>scm:git:[email protected]:user/project.git</developerConnection>
</scm>

4. The Release Plugin

The standard Maven plugin used by a Release Process is the maven-release-plugin – the configuration for this plugin is minimal:

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-release-plugin</artifactId>
   <version>2.4.2</version>
   <configuration>
      <tagNameFormat>v@{project.version}</tagNameFormat>
      <autoVersionSubmodules>true</autoVersionSubmodules>
      <releaseProfiles>releases</releaseProfiles>
   </configuration>
</plugin>

What is important here is that the releaseProfiles configuration will actually force a Maven profile – the releases profile – to become active during the Release process. Also setting autoVersionSubmodules configuration to true ensures that each module version is same as the parent version, if it is set to false, the user will be prompted for the version number for each module of the project.

It is in this process that the nexus-staging-maven-plugin is used to perform a deploy to the nexus-releases Nexus repository:

<profiles>
   <profile>
      <id>releases</id>
      <build>
         <plugins>
            <plugin>
               <groupId>org.sonatype.plugins</groupId>
               <artifactId>nexus-staging-maven-plugin</artifactId>
               <version>1.5.1</version>
               <executions>
                  <execution>
                     <id>default-deploy</id>
                     <phase>deploy</phase>
                     <goals>
                        <goal>deploy</goal>
                     </goals>
                  </execution>
               </executions>
               <configuration>
                  <serverId>nexus-releases</serverId>
                  <nexusUrl>http://localhost:8081/nexus/</nexusUrl>
                  <skipStaging>true</skipStaging>
               </configuration>
            </plugin>
         </plugins>
      </build>
   </profile>
</profiles>

The plugin is configured to perform the Release process without the staging mechanism, same as previously, for the Deployment process (skipStaging=true).

And also similar to the Deployment process, Releasing to Nexus is a secured operation – so we’re going to use the Out of the Box deployment user form Nexus again.

We also need to configure the credentials for the nexus-releases server in the global settings.xml (%USER_HOME%/.m2/settings.xml):

<servers>
   <server>
      <id>nexus-releases</id>
      <username>deployment</username>
      <password>the_pass_for_the_deployment_user</password>
   </server>
</servers>

This is the full configuration

5. The Release Process

Let’s break apart the release process into small and focused steps. We are performing a Release when the current version of the project is a SNAPSHOT version – say 0.1-SNAPSHOT.

5.1. release:clean

Cleaning a Release will:

• delete the release descriptor (release.properties)
• delete any backup POM files

5.2. release:prepare

Next part of the Release process is Preparing the Release; this will:

• perform some checks – there should be no uncommitted changes and the project should depend on no SNAPSHOT dependencies
• change the version of the project in the pom file to a full release number (remove SNAPSHOT suffix) – in our example – 0.1
• run the project test suites
• commit and push the changes
• create the tag out of this non-SNAPSHOT versioned code
• increase the version of the project in the pom – in our example – 0.2-SNAPSHOT
• commit and push the changes

5.3. release:perform

The latter part of the Release process is Performing the Release; this will:

• checkout release tag from SCM
• build and deploy released code

This second step of the process relies on the output of the Prepare step – the release.properties.

6. On Jenkins

Jenkins can perform the release process in one of two ways – it can either use it’s own release plugins, or it can simply run perform the release with a standard maven job running the correct release steps.

The existing Jenkins plugins focused on the release process are:

• Release Plugin
• M2 Release Plugin

However, since the Maven command for performing the release is simple enough, we can simply define a standard Jenkins job to perform the operation – no plugins necessary.

So, for a new Jenkins job (Build a maven2/3 project) – we”ll define 2 String parameters: releaseVersion=0.1 and developmentVersion=0.2-SNAPSHOT.

At the Build configuration section, we can simply configure the following Maven command to run:

release:clean release:prepare release:perform 
   -DreleaseVersion=${releaseVersion} -DdevelopmentVersion=${developmentVersion}

When running a parametrized job, Jenkins will prompt the user to specify values for these parameters – so each time we run the job we need to fill in the right values for releaseVersion and developmentVersion.

Also, it’s worth using the Workspace Cleanup Plugin and check the Delete workspace before build starts option for this build. However keep in mind that the perform step of the Release should necessarily be run by the same command as the preparestep – this is because the latter perform step will use the release.properties file created by prepare. This means that we cannot have a Jenkins Job running prepare and another running perform.

7. Conclusion

This article showed how to implement the process of Releasing a Maven project with or without Jenkins. Similar to Deployment, this process is using the nexus-staging-maven-plugin to interact with Nexus and focuses on a git project.