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
comments powered by Disqus

You might like also

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, economic model and solutions and provides a formal structure within which to compare them in this keynote presentation at Hyperledger Global Forum. …
43 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 …
43 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      …
43 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 …
43 Days ago
MAJOR BLOCKCHAIN CONSENSUS ALGORITHMS AS AN INFOGRAPHICS
Consensus algorithms enable network participants to agree on the contents of a blockchain in a distributed and trust-less manner. I’ve listed in the past few months all of them at tokens-economy.gitbook.io/consensus/ and thought it will be cool also to produce an Infographics The PNG (4528 x 2894 px, 2.5MB) can be downloaded here and the PDF version (280kb) with clickable consensus links here …
43 Days ago
No Thumbnail was found
Usually, a percentage of the tokens is sold to ICO participants and a percentage kept for the company’s needs. The token distribution and allocation of the token is usually a chapter in the future company whitepaper. A pie chart displays how and to whom tokens will be allocated. But how much tokens are allocated (amount) and what are they used for? how much token should I spend for advisor? is 15% of all tokens too much for founder? How many …
235 Days ago
No Thumbnail was found
introduction This is my attempt to list all possible blockchain consensus out there, I welcome pull request of the blockchain community! let's make it the main reference for blockchain consensus. Visit also Tokens-Economy.com to keep track of new developments in the distributed ledger technology space. Blockchain Consensus? At the core of the Blockchain disruption is a consensus algorithm: Consensus algorithms enable network participants to agree on the contents of a blockchain in a distributed and trust-less manner. “Consensus decision-making is a group …
246 Days ago
Initial Coin Offering security checklist
Blockchain technology and cryptocurrencies have revolutionized the way companies raise capital but at the same time are bringing their own sets of challenges. To ensure that your startup will go through that (ad)venture in a safe manner, you should always adhere to best security practices, for your company AND your investors.  This mind map will present you in a visual way lots of valuable information like: A compilation of the most dangerous threats to the ICO industry and how to mitigate, …
267 Days ago
Initial Coin Offering in most relevant countries
 This new rendering will allow you to better compare countries The rendering being dynamic you can also pass some parameters like https://ico.tokens-economy.com/statistics/collage.html?width=800&height=800 The default size is width=450&height=450 Filter by year ico end. e.g all ico ended in 2017 https://ico.tokens-economy.com/statistics/collage.html?year=2017  Filter by category and year https://ico.tokens-economy.com/statistics/collage.html?category=Cryptocurrency  And more ICO with no raised amount is also displayed now. ICO webpage has been added Text in bubble scale now properly and are always centered     …
281 Days ago
2751 coins, 47 Consensus and 82 cryptographic algorithms
The innovation speed in Blockchain landscape is just breathtaking and being able to (or to be honest trying to...) follow all these rapid changes is a chance for all software engineers. At the core of the Blockchain disruption are consensus algorithm: Consensus algorithms enable network participants to agree on the contents of a blockchain in a distributed and trust-less manner. And the consensus algorithm plays a crucial role in maintaining the safety and efficiency of blockchain. Using the right algorithm may bring a significant increase to the …
289 Days ago