We have a workflow requirement that essentially mean that we need to have the artifact version of a module externally defined from the current branch in git.
I.e. if we are on the master branch in git, I need <version>master-...</version>
and if we are on the bugfixX branch, I need <version>bugfixX-....</version>
for the generated artifact for this pom.xml.
I have previously found that https://github.com/koraktor/mavanagaiata can provide the SHA-1 hash as a property and it appears from the documentation that it can also provide the branch, so perhaps if it could be run early enough in the process we could set the property and just put <version>${our.version}</version>
in the pom. If this is possible, I would very much like to see a working pom.xml (and reward a 500 point bounty for it too).
If not, I guess we are into either preprocessing or "git checkout" do extra magic with some of the hooks (which I have not yet tried, working code would be great too).
We have a top level pom, which can be run to generate a property file in ".." before building the modules where this functionality I'm asking about needs to go.
Any suggestions on how to solve this?
Indeed, Maven can't change the version of it's own project in one run with other goals. On top of it, as far as I know, Maven doesn't support arbitrary properties in the
<version>
tag. Therefore, a separate execution is required to run a goal which will change the version of the POM. There are various plugins which can do it - for this case one might use theversions:set
goal fromversions
plugin - http://mojo.codehaus.org/versions-maven-plugin/set-mojo.htmlSo, one might execute it as follows for example:
where the
$branch
variable has to contain current Git branch name; it can be extracted withgit rev-parse
, like this:But still, one needs to execute it somehow. You can do manually, but it is cumbersome. So, my guess is that indeed the most robust solution would be to approach this from Git side. That is - a Git hook. Here is the complete Git
post-checkout
hook which will do the job (same code as above with some filtering to run the hook only when the branch is checked out, not the individual files only):Put this content to the file
PROJECTDIR\.git\hooks\post-checkout
file. Note that the hook file should be executable to run it (chmod +x post-checkout
).Few notes about
versions
plugin - it is pretty flexible and supports many options and have few other goals which might be of help, depending on your project structure (do you use parent poms or not, do childs have their own versions or do they derive from parent, etc.). So, the hook above might be modified slightly to support you specific case by using other goals fromversions
plugin or by specifying additional parameters.Pros:
Cons:
UPDATE
Hereafter is the more complicated version of the hook, which will not only set the version to the branch name, but will also preserve the suffix of the old version. For example, provided old version
master-1.0-SNAPSHOT
, switching tofeature1
branch will change the version of the project tofeature1-1.0-SNAPSHOT
. This bash script suffers from few problems (requires branch names without dash symbol (-
) in the name, and only takes the version of the root pom), but may give an idea of how the hook may be extended: given a mix of mvn and bash commands you can extract and update quite a lot of the information in the POM.Have you tried using this plugin?: https://github.com/ktoso/maven-git-commit-id-plugin. You can configure it to generate a properties file with all the relevant info about your repo state:
Sorry to revive this question and to post very lately another solution but it is possible indeed to change maven version dynamically and to use some git features, a little bit like
git describe
would do.The project that does this is jgitver-maven-plugin (disclaimer; I am the author), it uses jgitver a jgit based library in order to derive maven project version from git information .
It is very easy to use as a maven extension
The extension can also be used as a plugin extension, and then allows more configuration , for example in case you would not like to use SNAPSHOTS. See the project page for a description of full usage scenarios.
There is also a gradle plugin available that does more or less the same.
[edit 1]: answer to Thorbjørn Ravn Andersen comment
The plugin does not modify the original pom files or the build.gradle files.
For the maven plugin, modifications are done both in memory in the maven Object Model and written to a temporary file in temp directory. The calculation is based on the git metadata only (tags, commits, ...).
This non modification allows to not pollute the git history. WHen your are satisfied with a git commit, tag it
git tag -a x.y.z
andmvn deploy
: that's all.The version in your project files, is now useless and can be set to 0 for example.
As of today, and due to IDEA-155733 only recent EAP versions of IntelliJ work with the maven plugin. Eclipse & Netbeans have no problem.
Disclaimer: I am the author
My maven core extension will virtually set the version based on the current branch or tag. You can config custom version format patterns as you like.
https://github.com/qoomon/maven-branch-versioning-extension
Version Format Example
Have you checked the buildnumber-maven-plugin which gives you the opportunity to use the revision number of git. But you needed something different. Furthermore i would suggest to do a thing like:
beeing on master
on a branch you can simple change the version to
From maven-3.5.0 on there is support for ${revision}, ${sha1} and ${changelist} properties within the version tag. This feature may be sufficient for your purpose if, for example you want to incorporate the Git branchname into the version for a CI build job. See Maven CI Friendly Versions
Basically, in your pom.xml replace the fixed version by:
Set default values for revision and changelist in the project root dir by creating a file
.mvn/maven.config
containing:Check this file into version control, update it when you bump your project revision.
In your CI system you can then override the changelist variable using a cleaned-up representation of the Git branch name, eg.
(You may prefer
git symbolic-ref --short HEAD
for fetching the branchname, YMMV)Your artifact built by the CI system for branch
feature/branchname
will then have a versioned-branch suffix like:whilst developers who do not use any overrides will still build it as: