I use the maven release plugin a lot. It works flawlessly so far, but one thing annoys me. Look at my latest release command I just fired (mvn release:prepare):
I worked on the current version 1.4.0-SNAPSHOT (built a few new features etc.) It's the "normal" release train, speaking I am not patching this version but rather bringing a new version on the road. My 1.4.0 shall now be finished and released.
After that I want to be working on version 1.5.0, the next release, as this is my new planned version. But the release plugin makes suggestions/autocomplete for patch level (third number, 1.4.1-SNAPSHOT in my case). I want it for minor level (second number, so that it suggests 1.5.0-SNAPSHOT).
If there are fixes to be done, I usually branch a tag, fix the bugs, and release a patch (1.4.1 for my case), and merge it back into my trunk, providing the 1.5.0 version the same bugfixes.
I am unsure if this is "the right way" or if there is even a really right way, but that's how we work in my company.
So my question is: Is there a way to adjust the maven release settings so that it suggests minor updates rather than patch updates?
As of today I need to type my desired versions by hand (no biggie, but I am curious if maven might be able to support me here).
PS: I found some SO questions but their answers didn't fit me well. Also they are a few years old, maybe now there are proper solutions without some groovy scripts or similar ...:
Using maven release plugin autoVersionSubmodules to increment Major version
Maven release: next development version in batch mode
The SemVerVersionPolicy can be used to update the minor version.
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>3.0.0-M4</version>
<configuration>
<projectVersionPolicyId>SemVerVersionPolicy</projectVersionPolicyId>
</configuration>
</plugin>
This will propose the version 1.5.0-SNAPSHOT instead of 1.4.1-SNAPSHOT.
Related
I'm using maven release plugin to deploy new versions of software.
When running
mvn release:prepare
mvn release:perform
Everything works as expected.
If I tell maven to release version 2.1, it publishes an artifact 2.1 as well as a 2.2-20210205.061032-1, which I guess is some kind of snapshot. I'm wondering if it´s possible to perform a release for a new snapshot version ONLY?
The use case being that I have made some changes I want to publish for testing, before commiting to a final release. Something like 2.2-SNAPSHOT, or something like 2.2-YYYYMMDD.HHmmSS-X.
When prompted by maven to enter the next version, if I enter 2.2-SNAPSHOT, it just repeats the question again.
Please advice on how to achieve this, or if I'm thinking about this the wrong way.
If you want to deploy a SNAPSHOT, just run
mvn clean deploy
The Maven Release Plugin is meant for release versions.
SNAPSHOTs are meant to be very fluid, to the level of a dependent project "immediately" picking up changes to the SNAPSHOT dependency, whatever "immediately" means: it could be directly in an IDE, or while doing rapid builds on a command line but also on a CI server. I agree with the answer of J Fabian Meier that you can deploy a SNAPSHOT using mvn deploy.
However, if you are delivering a pre-release version for testing to a different team, you probably want them to have something that is more stable than a SNAPSHOT. When testing it is often important that you can reason about what version (or constellation of versions) you are running, and this is not quite the case with SNAPSHOTs (you may push up a new version then by quasi-accident, users may or may not force-update their SNAPSHOTs, or Maven may not look for new SNAPSHOTs until tomorrow).
You may be better off with versions that are released (from Maven's perspective) using the Maven Release Plugin (and benefit from the safeguards it offers), but just using version "numbers" that indicate it is a pre-release: 2.2-rc, 2.2-beta (I'm sure SemVer has ideas of the exact pattern to use, and so does Maven).
http://www.springsource.org/downloads/sts-ggts
I am trying to download new STS tool. On the above site I find
Milestone Version and Release Version. Can anyone tell me what these terms mean? Which is Users version to be used and is completely developed and not under-development?
The release version is the one you want, "release" means it's considered to be done and ready for the public. "Milestone" means it's a stable checkpoint made available for community developers to test. You'd pick the milestone one if there are new features or bugfixes you want to try out that haven't been included in a release yet.
I am thinking about a deployment pipeline using SVN, Jenkins and Maven. At the moment I'm stuck at the point where I usually would call mvn release:perform on a working copy.
When thinking in deployment pipelines, I want to create a pipeline where every commit could be used to release a software to test/production. Let's say I have 5 builds, and I decide to release build 3 (with revision 3) to production. There will already be 2 new commits to trunk (which is now at revision 5).
Is it possible to use the maven-release-plugin to checkout/build/tag/commit a release at revision 3? When the maven-release-plugin finishes the release it usually commits the modified POMs to trunk.
I'm happy about any kind of information or advice here, so feel free to point me to books (like http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912), blog posts, Jenkins documentation... Maybe I'm completely on the wrong track.
By default, the release plugin creates the release based on the contents of your working copy, it just ensures that you don't have any uncommitted content before doing so. AFAIK it doesn't force an update of the sources, as that's usually the job of the Continuous Integration system (Jenkins in your case). So whatever is checked out by Jenkins will be released.
What you're trying to do sounds more like a configuration change on the Jenkins side, pointing it to the right revision.
On the other hand, if the POM files are modified as part of the release, but have been changed in SVN in the meantime, you will run into a conflict when Maven wants to check in the modified POM files. That's a situation that might happen, depending on how for back you want to go with the release.
Based on this, it might make more sense to always create a branch before doing a release. So you would create a branch based on revision 3 and then create your release in that branch. This way, you wouldn't run into issues with committing resources that have changed in more recent revisions.
Creating the branch and checking it out could probably be automated through Jenkins and Maven as well.
As far as I tested it, it is not possible.
More explicitely, as nwinler said, when you release, maven try to commit the modified pom. But, if it's an older revision than the current one, SVN will complain that your sources are not up to date. So it won't work. ... as far as I know.
You may read docs about promotion build. I don't find any one clear enough to be pointed out (in th few minutes of the writing of this message).
I've been trying to build the 3.2.2 and 3.2.3 tags of WSO2 Carbon from here using Maven 2:
https://wso2.org/repos/wso2/tags/carbon/3.2.2
https://wso2.org/repos/wso2/tags/carbon/3.2.3
However, the Maven pom.xml files throughout the directory trees beneath these tags still refer to version 3.2.0 in both cases - am I missing something obvious please?
When I try and analyse the results of both the builds using our in-house tool I get identical results in the two cases (and indeed results that are identical to those for 3.2.0), which makes me think I may be building 3.2.0 repeatedly by accident.
3.2.2 and 3.2.3 are point releases and typically involves bug fixes/optimizations that do not introduce new features to the 3.2.0 release. If a particular component do not have any fixes/changes, the version still be the older version, no new version is introduced. This is how the versions are handled.
You're not missing anything. It seems they did screw up. Maybe that was their intention, but then it doesn't make any sense at all (at least for me).
I have the feeling I'm doing something wrong here as I have been digging around the net for a while (stackoverflow included of course) and yet that rendered no results!
In brief, I have a maven project set up with maven release plugin which works fine, increments the version correctly, checks in code in SVN, tags and deploys with no problem.
However, the need has arrived to also generate a script with each release which has to reference the jar generated. This means 2 things:
for the release version, change the script to contain the release version, commit it back in SVN (so it gets tagged etc)
following the release, the script has to be updated to contain the (next) SNAPSHOT version and committed back into SVN
For example, let's assume my current working version of the pom is 1.1.1-SNAPSHOT. As such my script.sh contains a reference to project-1.1.1-SNAPSHOT.jar.
When I perform a mvn release:prepare (assuming I will stick with the versions suggested by maven-release-plugin) the release version will become 1.1.1. At this stage, my script.sh should be changed to reference project-1.1.1.jar and committed back in.
Upon mvn release:perform all the 1.1.1 the tagging occurs, deployment to maven repo etc. And following that, my pom will be changed to 1.1.2-SNAPSHOT and committed back in SVN. At this point my script needs to be changed to reference project-1.1.2-SNAPSHOT.jar.
I figured out I can alter the script easily by using something like GMaven plugin -- and I have got the script in fact to kick in during prepare-resources phase (though maybe I need to look at another one?) however the biggest problem I see is retrieving the versions that maven-release-plugin has decided to use: in other words, how do I find out:
release version that maven-release-plugin has decided to use
next dev/SNAPSHOT version that maven-release-plugin will use
Once I get access to these I think I can get GMaven to execute the required code to change my script accordingly. (Though, if looking at the above scenario you can recommend a better way of doing this I would be more than glad to hear it!) Are there any properties like ${project.releaseVersion} (that doesn't work by the way) which could give me these 2 version numbers?
Thanks in advance!
Liv