During the life of a software project, there comes the time to create a package with a stable version of that project: this may involve several actions, such as clean the code, commit and/or tag, change the software version, upload the generated package to a repository.
Maven has a plugin to manage the whole procedure: maven-release-plugin.
Indeed this plugin is quite discussed and alternatives exist, but for my basic need I prefer this”native” choice.
In this post, I will focus on the environment and project setups needed by this plugin.

The plugin usage is not too difficult. The commands to issue are:

  • mvn release:prepare – to check the code, decide the versions (current release version and next development version) and configure the actual release procedure;
  • mvn release:perform – to actually do the release;
  • mvn release:rollback – to revert modification if something goes wrong.

Please read the plugin documentation, to understand what is really done and how to customize the behaviour.

Here, I’m more interested in the maven and project setups: few steps are needed in order to use the plugin.

1 – Environment: SCM client

Your workstation will need a client software to manage CVS, SVN, Git, …, because Maven will execute commands to commit, tag and checkout your projects.

Last time I’ve made this setup, I configured a Windows system to work with SVN: I’ve found an SVN client list here  and installed the CollabNet packages (adding the installation directory to the path environment variable).

2 – Maven settings: SCM server credentials

In order to access the SCM server, Maven has to know your username and password, that will be passed to the SCM client when executed.

Your Maven’s settings.xml should have a server entry similar to this:

<server>
  <id>my.svn.server</id>
  <username>my_username</username>
  <password>my_password</password>
</server>

3 – Maven batch

I think this step is needed only in Windows, because some Maven plugin tries to execute mvn.bat instead of mvn.cmd.

In the Maven bin directory, copy mvn.cmd mvn.bat .

4 – Project: SCM connection

In the project’s pom.xml, add an “scm” section with a “developerConnection”, if not already present:

<scm>
  <developerConnection>scm:svn:https://my.svn.server/path/to/project/trunk</developerConnection>
  <url>https://my.svn.server/path/to/project/trunk</url>
</scm>

To verify the setup, you can use any Maven’s SCM command, for example:

  • mvn scm:validate
  • mvn scm:status

5 – Project: distribution management

In the project’s pom.xml, add a “distributionManagement” section with repository and maybe snapshotRepository subsections, if not already present:

<distributionManagement>
  <repository>
    <id>nexus</id>
    <name>nexus</name>
    <url>http://my.server/nexus/content/repositories/releases</url>
  </repository>
  <snapshotRepository>
    <id>nexus</id>
    <name>nexus</name>
    <url>http://my.server/nexus/content/repositories/snapshots</url>
  </snapshotRepository>
</distributionManagement>

6 – Ready

Now the project is configured to be released.

When you think it’s time for a new release, you have to:

  • execute mvn release:prepare
  • answer 3 questions about version numbers and SCM tags
  • execute mvn release:perform

If the “prepare” phase goes wrong (uncommitted modifications, source code errors, …), you should fix errors, commit changes and try again, maybe after a mvn release:rollback command.
If present, files created by the release plugin could be ignored by the commit procedure (for example: release.properties).

Annunci