Problem with the maven release plugin

You may recognize yourself with the following use-cases:

  • We have several big modules/repositories with many branches. Per repository we have one parent pom and 50+ children poms. This is for a large JEE project (400 K lines of code) that it is delivered to several different clients.
  • We create feature branches, bug fixes, integration branches, release branches etc. We have many versions of the same application deployed to different production environments.
  • Every time a new branch is created, the version tag in the parent pom and all children poms need to be updated
  • When these branches need to be merged all these poms cause conflicts and they need to be manually resolved, because some times there are other changes in the poms besides just the version change. It is a major problem for us. 
  • We change the version on every branch because we have a continuous integration server that builds every branch and runs regression tests against every branch, therefore the versions must be different per branch.
  • Being able to keep the new version isolated to one file (the parent pom) really makes sense here. (Child pom inherits version from parent property)
  • We need to use SNAPSHOTS as we cannot have every developer build the whole system. Developers need to use artifacts built by TeamCity for their feature branch and they cannot be changing to the last build version they depend on every time a new development build is created.

The maven release plugin create a lot of issues that have been around for many many years.

The solution

Why you may want to set the version of your Maven poms from the outside? 

  • never changes and commit anymore Maven pom versions in every features, bugfix and releases branches
  • never having anymore pom conflicts while merging back features/bugfix branches to master or anywhere else

so you can also support pull request from anywhere without having to manually merging pom conflicts

The maven release plugin way

Prepare and Performing a release runs the following release phases:

  1. Check that there are no uncommitted changes in the sources
  2. Check that there are no SNAPSHOT dependencies
  3. Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
  4. Transform the SCM information in the POM to include the final destination of the tag
  5. Run the project tests against the modified POMs to confirm everything is in working order
  6. Commit the modified POMs
  7. Tag the code in the SCM with a version name (this will be prompted for)
  8. Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
  9. Commit the modified POMs
  10. Checkout from an SCM URL with optional tag
  11. Run the predefined Maven goals to release the project (by default, deploy site-deploy)

Some remarks

  • Maven poms are modified at step 4/8
  • SCM commit are done at step 6 and 9
  • SCM tag at step 7

see http://maven.apache.org/maven-release/maven-release-plugin/index.html

The new maven scm plugin way

only step number 5 is different! 1 to 4 are only here as reminders

  1. Checking out the software as it is (done by teamcity with a GIT clone)
  2. Giving it a version so it can be uniquely identified (done with a bash script that set the version to the branch name using mvn versions:set)
  3. Building, testing and packaging it
  4. Deploying it to an artifact repository where it can then be picked for actual roll out on target machines (3 + 4 mvn deploy)
  5. Tagging this state in SCM so it can be associated with the matching artifact   (new step using mvn scm:tag)

in your main pom.xml
you never change anymore the version, you can use MASTER-SNAPSHOT / 0-SNAPSHOT everywhere or anything else

    <version>MASTER-SNAPSHOT</version>

this is done already but not for release branches, this is because when we release, the maven-release-plugin check for local modification in reactors and refuse to commit something that has open changes (if we change the pom and dont commit them we have this case)
Now lets add the new maven-scm-plugin config and remove the maven-release-plugin

 <build>
     <plugins>
         <plugin>
             <groupid>org.codehaus.mojo </groupid>
             <artifactid>versions-maven-plugin </artifactid>
             <version>2.1 </version>
         </plugin>
         <plugin>
             <artifactid>maven-scm-plugin </artifactid>
             <version>1.8.1 </version>
             <configuration>
                 <tag>${project.artifactId}-${project.version} </tag>
             </configuration>
         </plugin>
     </plugins>
 </build>

Remark: The code above will tag automatically artifacts to ${project.artifactId}-${project.version} but you are free to use anything else. I personaly don't like to repeat the branch name into the version, so i recommend you to keep the default (${project.version})


All TeamCity builds are now identicals for bugfix, features and hotfix branches,
The release builds will add an additional deploy step before the plugin run
deploy scm:tag
so changes to the pom in reactor will be pushed to the tag in the GIT remote.

Conclusions

Faster release builds! less automatic commits, test cases do not run twice or 3 times, ...let’s resume how this solution compare to the standard maven way of releasing again:

  maven-scm-plugin maven-release-plugin
Clean/Compile/Test cycle

1

3

POM transformations

0

2

Commits                                

0

2 *

SCM revisions

1

3

* we don't want a second commit. One commit = one well defined state = one release candidate.

(References) bash script for all builds (bugfix, releases, features), for releasing builds remove the word -SNAPSHOT in version=    :-)

echo 'Will change the version in pom.xml files...'
branch=$(git rev-parse --abbrev-ref HEAD)
version="$branch-SNAPSHOT"
version="$(echo $version | sed 's/bugfix\///g')"
version="$(echo $version | sed 's/feature\///g')"
version="$(echo $version | sed 's/release\///g')"
version="${version^^}"
/home/agent/buildagent/tools/maven3/bin/mvn versions:set -DgenerateBackupPoms=false -DnewVersion="$version"
echo 'Changed version in pom.xml files to $version'
exit 0

References

  • http://maven.apache.org/scm/maven-scm-plugin/
    http://axelfontaine.com/blog/final-nail.html
  • http://blogs.atlassian.com/2013/05/maven-git-flow-plugin-for-better-releases/
  • http://jira.codehaus.org/browse/MNG-4715
  • http://axelfontaine.com/blog/maven-releases-steroids-2.html
  • https://github.com/axelfontaine/final-nail/blob/master/pom.xml

You might like also

A git workflow that is easy and scale for product development
There are numerous GIT workflow floating around like Centralized Workflow, Gitflow, Forking flow and Feature Branch Workflow Over the last 10 years, I have followed this really simple workflow, similar to the forking flow. it allow Parallel Development, features branches can be merged to any release branches or ideally Master Collaboration Feature branches also make it easier for two or more developers to collaborate on the same feature We consider Master the stable version of the product, this branch should be deployed automatically using …
16 Days ago
Using free Cloudflare for CDN and DDoS protection
Cloudflare, Inc. is an American web infrastructure and website security company, providing content delivery network services, DDoS mitigation, Internet security, and distributed domain name server services.  It will cost you 0$ (DDOS, CDN) to 20$ or more and offer you the following advantages DDoS is short for Distributed Denial of Service. DDoSis a type of DOS attack where multiple compromised systems, which are often infected with a Trojan, are used to target a single system causing a Denial of Service …
16 Days ago
Add Docker container logs in Splunk
With Splunk You will be able to optimize container usage by monitoring CPU, memory, disk and network performance metrics from your containers. Pay only for what you need by managing resources and measuring the impact on service reliability and container resource requirements. Get a complete overview of Kubernetes and OpenShift Environments Correlate performance metrics, container logs and OpenShift/Kubernetes configuration and metadata for a better understanding of how your infrastructure is performing and how hosted applications are behaving. …
16 Days ago
Installing latest Splunk in 5 minutes using Docker
From 0 to Splunk in 5 minutes using Docker and Compose Splunk is an American multinational corporation headquartered in San Francisco, California, which produces software for searching, monitoring, and analyzing machine-generated big data, via a web-style interface. Docker is an open source software platform to create, deploy and manage virtualized application containers on a common operating system (OS), with an ecosystem of allied tools.  Compose is a tool for defining and running multi-container Docker applications. With Compose, you use a YAML file to configure your application's services. Then, with …
16 Days ago
Explore 142 Initial Exchange Offering  (IEO) by category, year and country
IEO is currently the most popular fundraising trend in the crypto industry. As the name suggests, Initial Exchange Offering is conducted over the crypto trading platform and exchanges. So unlike ICOs wherein crypto projects directly approach investors, IEOs involve a third-party in the form of crypto exchanges. …
110 Days ago
Security Token Offering (STO) statistics
Security token offering (STO) is a type of fundraising that is performed with a company offering tokenized securities. The defining feature of security token offerings is in its definition. Stocks, bonds and managed property trusts are another examples of securities. …
111 Days ago
systematization of knowledge within major blockchain protocols or consensus
Alexis Gauba presented a systematization of knowledge within major blockchain protocols or consensus, addresses the common challenges …
189 Days ago
Stablecoins: Crypto's Holy Grail or Fools’ Errand? by Dr Garrick Hileman
I was attending the interesting LECTURE "Stablecoins: Crypto's Holy Grail or Fools’ Errand?" by Dr Garrick Hileman - Head of reseach at Blockchain - London School of Economics - United Kingdom at hashtagETH hashtagZurich and here is a copy of the slides Introducing: 2019 State of Stablecoins The 2019 report builds on its predecessor to provide an updated and expanded look at the current state of the stablecoin market - a space where we expect to see significant innovation in …
189 Days ago
The State of Stablecoins 2019: Hype vs. Reality in the Race for Stable, Global, Digital Money
The report, entitled “The State of Stablecoins 2019: Hype vs. Reality in the Race for Stable, Global, Digital Money” is based on information collected from 40 crypto and stablecoin firms. The report’s lead author is George Samman, a blockchain and cryptocurrency advisor. According to the document, Samman “was commissioned to research the stablecoin landscape and then independently report his findings for the broader industry to learn from.” https://bit.ly/2TWc1ao      …
189 Days ago
ICO STATISTICS FOR 2018 AND OUTLOOK FOR 2019
The last 6 months of ICO have been imported and can be browse at https://ico.tokens-economy.com/statistics. I display there historical ICO data for all cryptocurrencies friendly countries for each month of the year. What you can get out of all these charts: You can see the number of ICO per months over 13 major countries (Cayman-Islands, UK, USA, Cyprus, Estonia, France, Germany, Liechtenstein, Malta, Russia, Singapore, Slovenia, Switzerland), Each country has its own color, how often that color appear on the map represents the …
189 Days ago