Improved Releasing with Maven and Git

Author, Sander Brienen

Author, Sander Brienen

A note from TheNEXUS: As part of our series on Extensions and Plugins, we’re going to revisit some interesting projects to see how they are coming along. If you’ve got a project you’d like featured in the series, let us know.

by Sander Brienen

Back in 2012 I posted a blog post on setting up the Maven release plugin. Now Maven 3 has been out for a while, so it is time to review my findings.

The current version of the release plugin is 2.5.1. Using my previous blogpost as a guideline, I started a new Maven project with a new pom.xml containing this:

<project>
<groupId>nl.avisi.test</groupId>
<artifactId>avisi-test-pom</artifactId>
<version>1.0.3-SNAPSHOT</version>
...
<scm>
<developerConnection>scm:git:file:///opt/maven-demo/test-repo</developerConnection>
</scm>
<distributionManagement>
<repository>
<id>avisi-releases</id>
<url>http://localhost:8081/nexus</url>
</repository>
</distributionManagement>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.1</version>
</plugin>
</plugins>
</build>
</project>

As you can see, it has an scm tag, a SNAPSHOT version and a distributionManagement tag pointing to a Nexus repository. Ready to roll!

When I run release:prepare now, everything seems to work fine. And after release:perform, the process finishes perfectly and a new version of my test project is deployed to the repository. Version 2.5.1 also fixed the issue when the pom.xml is in a sub-directory of the repository. So multi-module projects will now work with the maven-release plugin as well.

What’s happened since 2012?

But a lot has happened since 2012. Git Flow was introduced, providing the world with a whole new branching model for git.

The basic idea of Git Flow is to develop on a separate branch called develop and create a new release branch whenever you want to release. The release:branch goal of the Maven release plugin seems a perfect fit to enhance our release process with. So I tried it out.

Experimentation

According to the documentation, the release:branch goal should do exactly the same as the release:prepare goal, except that it makes a branch instead of a tag. So I tried the following two commands:

mvn release:branch -DbranchName="releases/1.0.1"
mvn release:perform

Surprisingly, this did not work. Apparently, the release:branch goal doesn’t make any release.properties file or other files that the release:perform goal expects, so I tried this instead:

mvn release:perform -DconnectionUrl=scm:git:file:///opt/maven-demo/test-repo

Still no luck. The perform step seems to require certain settings that are not prepared correctly. So I abandoned this attempt and tried jgit-flow instead.

Git-flow branching model

Here is the code to perform a release following the previously mentioned git-flow branching model:

mvn jgitflow:release-start
git push --all
mvn jgitflow:release-finish

With release-start, a new branch is created for this release. I pushed this branch to the remote so others can review and check the release.

With the release-finish goal, the release is merged into the master branch and a new version of the project is deployed to the Maven repository. The release branch is deleted, but a tag is created instead. In order to start a new release, the old release branch must be removed first. To remove a remote branch, use git push origin –delete .

The jgit-flow Maven plugin also supports hotfix branches and feature branches.

Conclusion

Now, with this new Maven plugin, I think it is time to finally abandon the use of the maven-release-plugin…

The following two tabs change content below.
Sander Brienen is a senior software engineer, agile evangelist and development tool specialist at Avisi. After 10 years of working in the enterprise Java development area, Sander switched towards consultancy on Agile processes and software development tools in 2011. As an Atlassian Expert he became a specialist in all things Atlassian but as a true software engineer, Sander always looks over his horizon. Sander is an allround engineer, able to do Java development as well as server maintenance and build engineering. Sander founded the Agile Software Architecture Symposium and has been speaking on events several times since then. Sander his specialty is build automation. His vision is that every hour spent on building, deploying and delivering software is an hour wasted that could be used for building new functionality. In his role as development tool specialist he is helping many companies in creating their automated software build and delivery environment.

Latest posts by Sander Brienen (see all)

Authors

Related posts

One Comment;

*

Top