Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Ant, Maven and Other Build Tools and the fly likes Maven, Nexus, Jenkins and transition between development and release Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "Maven, Nexus, Jenkins and transition between development and release" Watch "Maven, Nexus, Jenkins and transition between development and release" New topic
Author

Maven, Nexus, Jenkins and transition between development and release

Peter Johnson
author
Bartender

Joined: May 14, 2008
Posts: 5812
    
    7

So I have set up Nexus and am using Maven for building and Jenkins for continuous integration. Now I am struggling with establishing a best practice for how to handle the transition form development to release and back to development again. Let me explain what I mean by that by giving an example.

I have a JAR that I am building. It has a pom.xml. When I make any changes, Jenkins fires off a build using deploy as the target, so the built JAR goes into Nexus. I need the JAR in Nexus because other builds rely on that JAR and need the latest changes. The version number for the JAR within pom.xml is 1.0-SNAPSHOT; having it be 1.0 would not work because all builds after the first would fail because you can deploy a specific version of a JAR only once to Nexus (yes, I know that that behavior is configurable).

So anyway, after developing for a while I decide that I am ready to release the official 1.0 version of my JAR. And after I do that, I would like to start working on version 1.1. My question is, what is the best way to go about doing this? I have a few options:

a) I could change the version in pom.xml to 1.0. Jenkins would notice the source code change and fire off a build and the 1.0 version would end up in a release repository within Nexus. Then I would change the version in pom.xml to 1.1-SNAPSHOT (which would trigger another Jenkins build) and continue with development.

b) I could use deploy:deploy-file with a slightly modified pom.xml (change the version to 1.0) to upload the last snapshot version of the JAR into Nexus. Note that this pom.xml would never get into source control - it exists only to do the upload. In fact, I could have a script grab the pom and strip the "-SNAPSHOT" off of the version number. This is sort of what the Version Maven Plugin does. Then in source control I could change the version to 1.1.-SNAPSHOT to continue development.

"a" sounds a little more straight-forward until system test and integration test enter the picture. I get weird looks from the integration test team when, after they tell me that all their tests passed and the product is ready to ship, I tell them, "That's great, let me rebuild everything to get rid of the snapshots." Thus "b" makes more sense.

How are others handling this situation? What are you doing to handle the version numbers for your JARs and other artifacts?

JBoss In Action
 
jQuery in Action, 2nd edition
 
subject: Maven, Nexus, Jenkins and transition between development and release
 
Similar Threads
linking my own application jar file to my maven build.
Could not resolve dependencies for maven project
maven subversion
how do i send a email test report from maven
Maven project running problem