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
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).
I would like repeatable results when running maven commands locally, even if somebody else is pushing updates to a snapshot dependency.
To achieve this, I would like to use the updatePolicy of never.
This will allow any dependencies that aren't available locally to be downloaded, while any I have installed locally will be used.
The offline flag won't work in this situation, as there may be dependencies that I haven't installed locally which will need to be downloaded from the remote repo.
I don't want to have to modify the pom, as doing this locally with every checkout will be error prone, and I don't want to commit these changes as it will have adverse effects on other developers.
Ideally I'd like to specify this from the command line. The opposite of the -U flag.
I've searched the docs, and so far have not found out how to do this.
If you want repeatable builds you can create a Docker image that can run Maven. Then load all you project files and run Maven build.
This will provide a clean environment for your build every time.
About the changing dependencies, if you work using SNAPSHOT dependencies, you must expect this different results. That is what SNAPSHOT means: "this is under development".
If you (or your team) control the SNAPSHOT dependency and there is an error in the build that's a "good" sign, the tests found something to be fixed.
If you (or your team) don't control the SNAPSHOT dependency, you would prefer to the last stable release.
I have a Jenkins job that builds a simple Maven project. If all I do is build, it works just fine. The problem arises when I try and do a release, dry run or regular. It consistently fails with the Cannot prepare the release because you have local modifications error. I have wiped out the workspace, but the problem persists. Is there any way I can get Maven to tell me which file it thinks has been modified? I would assume that by wiping out the local workspace and immediately running the dry run release that there wouldn't be any opportunity for anything to get modified.
Please note, I do not have access to the Jenkins server or the slave that is running the actual release build, so I can't use any tools there (like SVN) to determine what is supposedly modified.
You can use the Maven SCM plugin to do a diff.
https://maven.apache.org/scm/maven-scm-plugin/diff-mojo.html
Basically, integrate the maven plugin upstream of the failure, and see if anything has been changed. I imagine you might be able to see the output in the log, but if you cannot, you might be able to move your "real" maven pom.xml aside and replace it with one that generates a diff file and with the help of the maven build helper plugin, attaches that file as an additional aritfact (to a pom target).
It turned out the solution to my problem was to not use the "Local to the workspace" strategy for my private Maven repository in the Jenkins job configuration. By changing that to the "Local to the executor" strategy the problem went away. I'm still not sure why it was having the problem in the workspace, but this solution resolved it form me, and might work for others.
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'm learning how to use the Maven Release Plugin and I have a question with the process of tagging/branching. I'm working on a project called "test" version 1.0-SNAPSHOT. I'm ready for the release. I can prepare the release and perform the release but Maven only creates a tag and I also want a branch for maintenance (bug fixes). I know that there is a possibility to branch with the Release plugin, but the branch goal doesn't create a tag also. I understand that when you want to branch, you don't want to tag. But, generally when you create a tag from the trunk (because release 1.0 in this case), you would want to branch for future maintenance.
Is there a way to configure the prepare/perform goal(s) to also branch the project before or after creating the tag?
Thanks
AFAIK no. But simply copy the /tag/test-root-1.0 to /branches/test-root-1.0. Then you need to update the versions in the pom. For this you can simply use the "mvn versions:set" goal and set the version to "1.0.1-SNAPSHOT". You are probably up to scripting these two commands in bash script if you need to make it look as one :-)
You might want to consider integrating the maven-scm-plugin into the mix. Either scm:tag or scm:branch before or after your release goals should do the trick.