By default all maven projects have a version number that you increase upon releases whether it's a minor or major release.
When you are in a scenario in which you continuously deliver application (for example on a staging server) it's probably a good idea to have some unique build identifier so as to know the exact version that is deployed on the server
Luckily the guys over at codehaus have an app plugin just for that .
I'm talking about the buildnumber-maven-plugin
This plugins will generate a build identifier each time you compile your maven project and make this identifier available through a maven variable ${buildNumber}
The plugin can generate build numbers in 3 ways :
- SCM (my personal favorite)
- Sequential build number
- Timestamp
Personally I prefer the SCM approach since it's coupled with your commits, and I will here I will be showing how to do that
First you will have to configure the maven scm plugin with your details, otherwise you'll end up with error messages like :
Failed to execute goal org.codehaus.mojo:buildnumber-maven-plugin:1.2:create (default) on project simple-webapp: Execution default of goal org.codehaus.mojo:buildnumber-maven-plugin:1.2:create failed: The scm url cannot be null. -> [Help 1]
com.ufasoli.tutorial swagger-spring-mvc 1.0-SNAPSHOT ... scm:git:https://github.com/ufasoli/spring-mvc-swagger-tutorial.git https://github.com/ufasoli/spring-mvc-swagger-tutorial.git
Here I'm using a github repository as SCM
Once your SCM details are set you can configure the build number plugin :
... org.codehaus.mojo buildnumber-maven-plugin 1.2 validate create false false 5
Here I'm configuring the plugin with 3 worth noting options
- doCheck : Check for locally modified files. If true build will fail if local modifications have not been commited
- doUpdate : Update the local copy of your repo. If true the plugin will update your local files with the remote modifications before building
- shortRevisionLength : shortens the git revision to the number of characters specified in the tag (5 in our case)
Once everything is configured you will be able to access the ${buildNumber} variable in your pom (even though your IDE might complain that the variable cannot be resolved don't worry it will be there when you package your project)
${project.artifactId}${project.version}_${buildNumber}
Great article - you will need to fix your tags so they are camel case.
ReplyDeleteHi thanks,
DeleteYes it's weird the tags are properly camelCased on my code but something goes bad when the code is processed by the syntaxHighlighterPlugin
Nice article.
ReplyDeleteLet me give you some fixes ;)
the tag is called finalName not finalname.
groupId not groupid
artifactId not artifactid
For your final name you are using deprecated variables.
It should be ${project.version} instead of ${version}
Also you could generalize the finalName like this:
${project.artifactId}${project.version}_${buildNumber}
based on the previous comment, ignore the camelCase thing. :P
DeleteHi, thanks for the comment and the fixes. I updated the code to reflect the new variable names as well as the better finalName generalization.
DeleteCheers
Ulises
Hey, cheers for the article. Looks like finalname still isn't fixed to be finalName, just fyi :) Otherwise looks great.
ReplyDeleteHi thanks for the message. yes the camel case thing is a bug in the JS library used for code syntax highlighting..
DeleteshortRevisionLength is casesensitive.
ReplyDeletehttp://stackoverflow.com/questions/34122516/why-is-shortrevisionlength-property-in-pom-xml-ignored?noredirect=1#comment55993746_34122516
Hi,
ReplyDeleteyes as indicated in the previous comments the JS library used for syntax highlighting makes the tags in lowercase.
can this same approach be used for TFS repository> please advise.
ReplyDeleteHi,
ReplyDeleteI've only used TFS to store git repositories and in that case it works; I guess it should work using native TFS but I cannot tell you for sure.