Maven Release Plugin releases SNAPSHOT instead of STABLE version

mavenThere has been a lot of fuss around this issue and it seems there are already fixes in place. But in certain use-cases problems persist even if you apply fix mentioned in MRELEASE-812 issue or this ShredZone article. So if you experience the behaviour described in the title of this article keep on reading I may have a fix for you or at least I can help you debug the problem.

Fix for complex folder structures

If you have following project structure:

  • superproject [Git repository root]
    • projectA [release target]
    • projectB [release target]

in other words you release subproject of a larger Git repository separately, you probably run at the same issue as we did. No recipe from above mentioned sources solves your problems and during release:prepare phase still no commit of stable pom.xml occurs. There is another bug in GitStatusConsumer class that checks output of the git status --porcelain command and verifies existency of the mentioned files on local filesystem. Regretfully it uses working directory instead of git repository root (that was previously retrieved by git rev-parse --show-toplevel) as the base folder and thus it constructs invalid path to the file where project folder directory is duplicated.

Reported bug is here: http://jira.codehaus.org/browse/MRELEASE-864

Till the proper fix is released by Apache you can upload fixed plugin JAR into your internal repository. You can downloaded patched wars here:

Plugin POM: download
Plugin JAR: download
Plugin Source JAR: download

Recipe for debugging similar type of problems

If you ever run into the similar issue in the future you can easily debug such problem if you do following steps:

  1. checkout maven-scm-providers repository from git:
    git clone https://git-wip-us.apache.org/repos/asf/maven-scm.git maven-scm-git
  2. open project in your IDE and place breakpoint into the class
    org.apache.maven.scm.provider.git.gitexe.command.status.GitStatusConsumer
  3. run maven release:prepare goal in following way
    mvnDebug release:prepare
  4. Attach debugger on a port 8000 (maven will wait for it) - you should use something similar to
    -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000
  5. Debug the problem in the class :)

This one took me several hours but next time I will be faster ... I hope there will be no next time :)