The Maven release plugin is a very powerful tool and I rely on it heavily for coordinating software releases. Typically, software release version numbers follow a simple
22.214.171.124-SNAPSHOT format. But recently I had need to add a qualifier to the version number – something like
1.0.0-fix-bug-description-SNAPSHOT. After my 1st attempt to add the qualifier, the Maven release plugin auto-incremented the version number in an unexpected way. Therefore, I needed to research the Maven release plugin version auto-increment behavior but do so without making a bunch of nonsense tags in the production Git repository (I didn’t have a dev repository to work with). The purpose of this blog is to show how the Maven release plugin can be configured so it can run locally and not make changes to production source control.
This post is solely informative. Critically think before using any information presented. Learn from it but ultimately make your own decisions at your own risk.
I did all of the work for this post using the following major technologies. You may be able to do the same thing with different technologies or versions, but no guarantees.
- NetBeans 11.2
- Maven 3.3.9 (Bundled with NetBeans)
- maven-release-plugin 2.5.1
- Java 11 (zulu11.35.15-ca-jdk11.0.5-win_x64)
- Git for Windows 2.25.0
NOTE The Maven release plugin assumes executables (like git) are on the
PATH. If you get an error that the
git command is not found, you need to make sure Git is installed independent of your IDE and on the
Visit my GitHub page https://github.com/mjremijan to see all of my open source projects. The code for this post is located at: https://github.com/mjremijan/thoth-maven-release-plugin
The 1st thing you’ll need to do is install Git. Even if Git is integrated into your IDE (like with NetBeans), the Maven release plugin assumes the executables it needs are available on the PATH. Download, install, and configure PATH for your environment.
POM <scm> Tag
The 2nd thing you’ll need to do is configure the POM <scm> tag. When the Maven release plugin runs, it uses the <scm> tag values to identify the location of the source control system.
The relevant configuration is below, see the full pom.xml on GitHub.
Because I want to run locally and not connect to a production source control system, my example uses Git. Git runs very nicely without needing a server. Let’s take a look at the <scm> tag.
Listing 1 – <scm> tag
The code in Listing 1 shows my configuration for the <scm> tag. Obviously, the reference to the project’s
.git folder on the file system of my computer should stand out to you. You must change this value for your computer. Remember, the goal is to work locally! This configuration gets you there.
After configuring the <scm> tag, the next thing to do is configure the maven-release-plugin. Let’s look at that next.
The 3rd thing to do is configure the maven-release-plugin artifact. This configuration is for the Maven staging repository.
The relevant configuration is below, see the full pom.xml on GitHub. Let’s take a look at this configuration.
Listing 2 – maven-release-plugin tag
Line 6 sets the maven-release-plugin to version
2.5.1. This was current at the time of my research (2019 Q2). Using a version below
2.5.2 has some additional gotchas which I’ll get to next.
Line 8 sets the maven-invoker dependency to version
2.2. Maven 3.3 changed the script name (on Windows) from
mvn.cmd. The maven-release-plugin below version
mvn.bat. Changing maven-invoker to version
2.2 changes the assumption to
mvn.cmd so Maven 3.3+ can be used (Lucas, 2015). If you use maven-release-plugin greater than or equal to version
2.5.2, you don’t need this maven-invoker configuration.
Line 15 sets the location of the Maven staging repository. Typically you would have this set in
settings.xml. If it’s not set, you’ll get build errors. I show how to configure it here. If you have it in
settings.xml you can remove this configuration.
Now that the
pom.xml is configured, let’s look next at how to run this.
With the configuration now set, it’s time to run the Maven project and test that everything is working. Listing 3 shows the properties and switches for
Listing 3 – mvn command
There is not much to this command line. Line 4 is the most important. It specifies the maven-release-plugin goals to execute.
Now you are ready for testing. Run the command and see what happens.
If you are using an IDE like NetBeans which automatically watches and reloads files when changes are detected on the file system, you can open the
pom.xml, then run the
mvn command, and finally watch the <version> tag automatically change as Maven is running. This way you can start with whatever value you want for the <version> tag and research how it automatically gets changed. Enjoy!
Lucas. (2015, July 1). Failed to execute goal maven preprepared [Web log comment]. Stackoverflow. Retrieved from https://stackoverflow.com/questions/29755620/failed-to-execute-goal-maven-releaseprepare.
Published on Java Code Geeks with permission by Michael Remijan, partner at our JCG program. See the original article here: Testing Maven Release Plugin Auto-Increment Version Number
Opinions expressed by Java Code Geeks contributors are their own.