I am not sure if I am doing something wrong here, or if there is a bug in maven-release-plugin. But when I try to release a version 1.2.1, maven creates a tag with the right version, but the version number set in the tag's pom.xml is set at 1.2 (not 1.2.1 as it should).
This is what I do when I tried to fix a bug in 1.2:
svn cp URL/tags/myapp-1.2 URL/branches/myapp-1.2
edit project.version in URL/branches/myapp-1.2/pom.xml to be 1.2.1-SNAPSHOT (was 1.2)
fix the bug in the source
commit changes
mvn release:prepare
#when asked, use the defaults: release version 1.2.1, next dev version 1.2.2-SNAPSHOT
[INFO] BUILD SUCCESSFUL
OK so far, but if I check out the code in the new tag the version is wrong! URL/tags/myapp-1.2.1/pom.xml has version 1.2, not 1.2.1 as the tag name should suggest. If I just run mvn release:perform now, the new uploaded jar will have its name set to myapp-1.2.jar, overwriting the original in the repository.
I have upped the maven-release-plugin version from 2.0 to 2.1, but with no greater success. I know the thing that causes this error is the part of the process where the plugin does this:
svn --non-interactive copy --file /tmp/maven-scm-2371633.commit --revision 19866 URL/tags/myapp-1.2 URL/tags/myapp-1.2.1
This copies the source from tags/myapp-1.2 to tags/myapp-1.2.1, but this does not contain any changes. Do you agree that it should have copied from branches/myapp-1.2, not the tag?
Is this working for anyone else, and do you see if I am doing anything wrong?
You need to verify if the repository link in your pom is pointing to a branch instead of the trunk.
If that is the case, then you'll get the error. Point it to the trunk, instead.
Related
I have in my pom this section:
<groupId>com.sample.app</groupId>
<artifactId>simpleapp</artifactId>
<version>1.0.9-${buildNumber}-SNAPSHOT</version>
<packaging>war</packaging>
Is there any nice and "maven way" to keep this variable name ${buildNumber} in that place in pom as this is now?
I mean - when I am performing
mvn deploy:prepare deploy:release -DbuildNumber=${BUILD_NUMBER}
this version section in pom.xml is updated to (when BUILD_NUMBER eq: 12):
<version>1.0.9-12-SNAPSHOT</version>
which almost is ok but this is also commited to repository. I like the fact that this tag: 1.0.9-12 in git repo is created, but I prefer to keep my original format of version in pom.xml file:
<version>1.0.9-${buildNumber}-SNAPSHOT</version>
This is because this stupid approach I have in my company to add to artefact version also build number from CI tool :(
Can someone give me some hint how to handle this?
The Maven Release Plugin has a parameter called developmentVersion that allows you to set the new version that is committed to your git branch after the release is done.
If you want to tell the Release Plugin to reuse the parts of version you used before, the Build Helper Maven Plugin helps you to parse the version. It creates properties like majorVersion and minorVersion from which you can construct the target version you like.
UPDATE:
I've added dependency for this helper plugin and final result is like this:
mvn --batch-mode \
build-helper:parse-version \
-DdevelopmentVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion.nextIncrementalVersion}-\${parsedVersion.qualifier} \
-DreleaseVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion.incrementalVersion}-31 \
release:clean \
release:prepare \
release:perform
I removed this ${buildNumber} as it is not required - Build Helper Plugin helped me a lot - I do not need any additional step in CI plan.
Now I have autoincrement and during release I am able to add build plan ID.
For me case solved :-)
I would like to have a new version on every commit in the master branch.
Since I'm using gradle to build, I found 2 nice plugins, Release https://github.com/researchgate/gradle-release/issues/273 and Git Versioner https://github.com/passsy/gradle-gitVersioner-plugin.
I would like to manage daily commits with some version like 1.0.0.BuildNumber. This needs to create a tag in Git and push, but also I need to set the project.version tag with the right version because I need it for the springBoot buildInfo (I'm getting the BuildProperties in Spring to know the version I'm executing on).
When I try to run:
gradlew release -Prelease.useAutomaticVersion=true
It always fall back to 0.0.1 version.
I'm just using the default configuration of the plugin and I got lost ...
I still had the old project.version defined and the plugin was defaulting to that one.
I want to automate our branching process and for that i am using maven-release-plugin.
Following command is used for branching:
mvn --batch-mode release:branch -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=$MoveWorkingCopyToNextVersion
-DautoVersionSubmodules=true -Darguments="-DskipTests"
-DreleaseVersion=$BranchVersion -DbranchName=$BranchVersion
-DscmCommentPrefix=$ReleaseJira:
-Dusername=$BuildUser -Dpassword=$BuildUserPassword
My problem is that with above command version of pom created in branch is "BranchVersion-SNAPSHOT" while i want pom version in branch should be "BranchVersion" i.e. it should not contain snapshot.
I know this is not standard approach but our current release process will not work if branch contains "SNAPSHOT".
Any suggestions?
If you don't get updateVersionsToSnapshot working could you use the versions plugin afterwards to set the version on the Pom
http://mojo.codehaus.org/versions-maven-plugin/set-mojo.html
I checked out current SVN Snapshot of DWR (3.0.0-rc3-SNAPSHOT) and I am unable to mvn install it - the pom.xml seem to be configured not for such command. What is the correct way of installing DWR into maven repo?
I also tried copying files from https://oss.sonatype.org/content/repositories/snapshots/org/directwebremoting/dwr/3.0.0-rc3-SNAPSHOT/ and mvn installing them as well. This way obviously does not work either. How can it be installed from here? I don't want to link to the snapshot directory directory from my pom.xml as I don't want to get unexpected results when new snapshot is introduced.
I'm not sure if I get you correctly, but you can always download the JAR and install it locally using Maven. Something like this:
mvn install:install-file -Dfile=dwr-3.0.0-rc3-20130514.180049-1.jar -DgroupId=org.directwebremoting -DartifactId=dwr -Dversion=3.0.0-rc3-SNAPSHOT -Dpackaging=jar
more on the Maven info here:
http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
EDIT:
I managed to install it from source as well by do SVN checkout:
svn co https://svn.directwebremoting.org/dwr/trunk/
My first attempt to build it failed because I was using Maven 2.x. Seems like DWR is using Maven enforcer plugin to enforce certain Maven version. I didn't check which version is really required but by updating my Maven to Maven3 I managed to install it.
We use Maven with Subversion internally. We also use Maven's Release plugin. We noticed the issue described below when running through the following (correct, I presume) steps.
1. We run release:prepare:
Maven updates the trunk version to 1.0.0.
Maven runs svn copy trunk/myproject tags/myproject-1.0.0, thus creating tag myproject-1.0.0.
Maven updates the trunk version to 1.0.1-SNAPSHOT.
2. We run release:rollback:
Maven resets the trunk version to 1.0.0-SNAPSHOT.
Maven does not remove the tag, because Maven doesn't do this kind of stuff.
3. We commit more changes to trunk, obviously against version 1.0.0-SNAPSHOT.
4. We run release:prepare again:
Maven updates the trunk version to 1.0.0.
Maven runs svn copy trunk/myproject tags/myproject-1.0.0, thinking it created tag myproject-1.0.0 out of the latest trunk. But, alas, Subversion (1.6 and 1.7 alike) will instead create tags/myproject-1.0.0/myproject on Maven's behalf.
5. We run release:perform:
Maven checks out the contents of tag myproject-1.0.0.
Maven builds the contents and deploys the result to Nexus.
The problem is obvious: the change in step 3 did not make it into the tag. We are now releasing 1.0.0 without the change in it.
The questions are: How can we fix this? Is Maven's release rollback feature inherently broken?
In fairness, rollback should reset the project and SCM to a state that allows a second prepare to occur. This includes removing the tag. The answer is now apparent (Googling "maven release rollback remove tag"):
http://maven.apache.org/maven-release/maven-release-plugin/examples/rollback-release.html:
The created branch/tag in SCM for the release is removed. Note: This
is not yet implemented so you will need to manually remove the
branch/tag from your SCM. For more info see MRELEASE-229.
The resolution would then be to force release:rollback to include a command to delete the SCM tag using something like org.codehaus.mojo:exec-maven-plugin. Short of this, wrap rollback inside a script that does that externally.
As you've discovered, release:rollback doesn't have a whole lot of utility when it doesn't clean up SCM. What our shop has done is setup our Jenkins automation to run "mvn release:prepare release:perform" in combination with the Jenkins M2 Release Plugin.
If it fails we need to delete the tag in Subversion but, then again, we would have to do this anyway with rollback.