A coders, hackers heaven.....Hm...I do not think so...
Continuous Delivery With Maven
Based on todays requirements it is needed to do a continuous delivery of
your artifacts by each change on your master (Git)/trunk(SVN). The question
is what you need to achieve this with Maven?
Usually you are using so called SNAPSHOT versions which means your version
looks like 1.2.3-SNAPSHOT and indicates that you are currently working
towards the release version 1.2.3. Afterwards you continue with the next
snapshot version like 1.2.4-SNAPSHOT and so on.
Depending on your environment this has been changed which means that each change
you have made on master (Git) you need to produce a new release version which
means 1.2.3 and next will be 1.2.4. The development will be done on branches
where you might need a SNAPSHOT version.
Let us take a look into a single module pom file which looks like this:
The version is defined with 1.2.3-SNAPSHOT if you now call:
mvn clean package
You will produce artifacts which look like domain-1.2.3-SNAPSHOT.jar.
Unfortunately this kind of artifact is something which can change over the time
based on Maven philosophy. That means if you now make a change in your code
and just do it again mvn clean package it will create the
same domain-1.2.3-SNAPSHOT.jar file. There is no real difference if you
do an mvn clean install instead. This will only install the created
artifact into your local cache $HOME/.m2/repository. Furthermore if you do
mvn clean deploy the difference is only that each time you do this on your repository
manager the naming schema is a little bit different which means the artifact will
look like domain-1.2.3-20180821.202345-1.jar. So in the end the artifact contains
a time stamp. But the most important thing is that SNAPSHOT versions
are not immutable as you might have already realized based on the above.
So the only way to create real immutable versions is to create releases from Maven
point of view. This means you have to use a version without -SNAPSHOT.
So in consequence you have a pom file which looks like the following:
So you can do a mvn clean deploy and you have created an immutable
release artifact domain-1.2.3.jar. If you try to do this a second time your
repository manager will tell you that this does not work cause by definition
releases are immutable which means you can not overwrite them. So the
consequence is if you have made a change/mistake/fix to your project you have to
change the version number. Ok, not very complicated just change the version
to 1.2.4 commit and do another mvn clean deploy? So good so far.
Some people do not like the commits where only a version has been changed.
So the question is: Is there a more convenient way to handle this?
Starting with Maven 3.5.0+(I recommend to use the most recent version) there is a
more convenient way to handle that. You can write your pom file like the following:
So it is now really easy to create a release from the whole project by using the following
mvn -Drevision=1.7.0 clean deploy
This would result in a release deployed to a repository manager.
So now let us take a look onto using it in a continious integration solution like Jenkins.
On Jenkins you have often the situation to produce artifacts on a branch base (maybe SNAPSHOT
based to be able to deploy them to test environments).
So you can combine the properties like this:
This approach has the advantage that on each branch you are using a different version which
are distinguished by the -BRANCHNAME and those versions are snapshots. This is convenient
cause, all repositoy managers have support to delete snapshot versions after some time automatically.