Maven build number, versioning your projects builds automatically

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}



11 comments:

  1. Great article - you will need to fix your tags so they are camel case.

    ReplyDelete
    Replies
    1. Hi thanks,
      Yes it's weird the tags are properly camelCased on my code but something goes bad when the code is processed by the syntaxHighlighterPlugin

      Delete
  2. Nice article.

    Let 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}

    ReplyDelete
    Replies
    1. based on the previous comment, ignore the camelCase thing. :P

      Delete
    2. Hi, thanks for the comment and the fixes. I updated the code to reflect the new variable names as well as the better finalName generalization.

      Cheers

      Ulises

      Delete
  3. Hey, cheers for the article. Looks like finalname still isn't fixed to be finalName, just fyi :) Otherwise looks great.

    ReplyDelete
    Replies
    1. Hi thanks for the message. yes the camel case thing is a bug in the JS library used for code syntax highlighting..

      Delete
  4. shortRevisionLength is casesensitive.

    http://stackoverflow.com/questions/34122516/why-is-shortrevisionlength-property-in-pom-xml-ignored?noredirect=1#comment55993746_34122516

    ReplyDelete
  5. Hi,
    yes as indicated in the previous comments the JS library used for syntax highlighting makes the tags in lowercase.

    ReplyDelete
  6. can this same approach be used for TFS repository> please advise.

    ReplyDelete
  7. Hi,
    I'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.

    ReplyDelete