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.
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.
Now, with this new Maven plugin, I think it is time to finally abandon the use of the maven-release-plugin…