• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
  • Piet Souris
  • Himai Minh

Maven, Nexus, Jenkins and transition between development and release

Posts: 5856
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
Never trust an airline that limits their passengers to one carry on iguana. Put this tiny ad in your shoe:
Free, earth friendly heat - from the CodeRanch trailboss
    Bookmark Topic Watch Topic
  • New Topic