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).
Related
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 Jenkins version 2.7.1 running on a Windows 7 machine. It is successfully pulling code from a subversion repository and running tests. I have the test jobs set up for the development branch of each project only.
We periodically make stable releases of the projects in jar files with version numbers. I would like to have Jenkins be the repository manager for those stable releases. These are made by hand - There is no Jenkins job making or testing stable releases. The projects do use Maven.
Each stable build is tagged in the subversion repository, so it could be made again on demand if needed.
I downloaded the Maven repository server hoping to make this fit the purpose. I read the documentation that's provided, but it's pretty terse. As I understand it and have it configured now, this appears to have a couple of issues:
If I go to jenkins-ip/plugin/repository/project, it has made directories there that expose the names of all of my projects, which seems undesirable. (Here jenkins-ip is the IP where I access Jenkins on my local network.)
On the other hand, there's nothing but empty directories under these projects, so they're currently useless.
These projects all correspond to the continuous testing of the development branch. There's no apparent way to get the stable builds into the hierarchy. (It doesn't seem efficient to create a job for each stable release...)
Is there anyway to get Jenkins (with this plugin or through another method) to be the repository manager just for the stable builds? I know that I can start a different repository manager like archiva, but it would be ideal to use Jenkins since it's already running and it seems to claim capability for this function now.
To use Maven repository server you have to build the project on Jenkins.
Then the plugin will expose all archived artifacts as maven repo.
Note you need to use a "Maven project" type for it to work (freestyle is not supported)
There are several plugins that will help you manage building from multiple tags, however not all of them work with "Maven project" type.
You could also try Jenkins pipeline (previously "Workflow") or the Job-DSL plugin.
A simplest solution would be to have a build parameter specify the tag name (then checkout e.g. ^/tags/projectname/${tagParam}), but you have to figure out how to trigger the job then.
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 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
What would be a good way to get 'mvn deploy' for snapshot deployment to create a snapshot tag(x.y.x-20110304.mmhhss-1) in git using the snapshot version(x.y.x-20110304.mmhhss-1) identifier created by maven, release plugin creates release tags. I would like a tag for snapshots.
Thanks
-am
This feature is not supported by Maven (Snapshot) repositories. Snapshots are designed to be throw-away or development builds. Repository managers like Nexus often have background jobs which purge old snapshots.
The purpose of tagging is to be able to reproduce that binary again. If you really care, perhaps you should release more often?
Finally, some version control systems impose a rather stupid overhead on tagging operations (updating each file in the repository.... Clearcase, CVS, etc). This has traditionally discouraged tagging during a CI build (which would typically generate the snapshot release).