views:

327

answers:

1

I'm converting an ant project to a maven one. This project differs from the ones I've usually converted since it has very frequent releases, typically 8-10 times per day.

By release I mean that the resulting jar is packaged and included in the production enviroment. This project is a leaf one, so it publishes no API, it only consumes it. It is also at most a runtime dependency for two other projects.

I'd like to have a versioning scheme where:

  • it's easy to deploy without forcing the developers to think about what version number to assign to the project, since the number is meaningless;
  • It's easy to include the latest version of this project as a dependency without constantly bumping up dependency versions;

Most likely the dependency version would not be a -SNAPSHOT, since that would conflict with the maven-release-plugin we're using for other projects, but I'm open to suggestions.

+3  A: 

Actually, you can use x-SNAPSHOT version and still use the maven-release-plugin. Just use mvn release:prepare before mvn release:perform to prepare your release and change the version in the poms from x-SNAPSHOT to a new version (you will be prompted for the versions to use). You can check out this introduction to the maven-release-plugin for a quick overview of release:prepare and release:perform.

Then, to include the latest version without constantly updating dependencies version, you could use dependency ranges like in the following snippet where we specify a range Junit 3.8 - Junit 4.0:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>[3.8,4.0)</version>
  <scope>test</scope>
</dependency>

A version before or after the comma is not required, and means +/- infinity. For example, [4.0,) means any version greater than or equal to 4.0.

Personally, I don't like to use dependency ranges that much because I find that it can lead to build reproducibility issues and makes the build more fragile.

But you may have good reasons to use them.

Pascal Thivent
Thanks for the answer. I _might_ end up doing exactly this, but I still have the problem that versions and releases are irrelevant for this project - it's in a state of continuous flux.
Robert Munteanu
To my knowledge, you have 2 choices here: 1. using a snapshot version (good for continuous flow) and forgetting the release plugin but I wouldn't do this with production code 2. using the release plugin and incrementing versions (or maven won't pick updates). I don't know if there is a solution that meets in the middle.
Pascal Thivent
+1 for version ranges and the release plugin, see this answer for more options: http://stackoverflow.com/questions/30571/how-do-i-tell-maven-to-use-the-latest-version-of-a-dependency/1172371#1172371
Rich Seller
@Rich Do you know if the LATEST/RELEASE features are deprecated or not as stated in this message http://www.nabble.com/Re%3A-LATEST---RELEASE-dependency-version-p25566028.html
Pascal Thivent