Maven: How to ensure timestamped versions of snapshots are used in classpath?

Question

I would like our functional tests to run from Maven using the timestamped version (e.g. api-0.5.0-20110706.191935-1.jar) of snapshots in the classpath. However, while I can see that we have timestamped versions sitting in our Artifactory repository Maven is referring to api-0.5.0-SNAPSHOT.jar and resolving it from the local repository.

Background Our continuous integration (CI) server has two relevant builds set up. The Server build runs mvn deploy and the new snapshots turn up in the repository correctly built.

We also have a functional test build which gets the latest correct build, deploys to a development server and then starts running tests against it.

What appears to be happening is that the functional test build relies on API-0.5.0-SNAPSHOT.jar. When the Server build runs it replaces the snapshot in the local repository and we start getting NoClassDeFond errors from the functional test build.

Hence, I want the functional test build to use the timestamped versions.

Options I'm currently aware of:

1. Declare a snapshot repository in the POM and ensure uniqueVersion is true (I will shortly run a build trying this).
2. Use the version lock:snapshots goal to set the versions in the pom to the timestamped version.
3. Consider running the server build and functional tests in one invocation from the CI server. (i.e. removing the Server build).

Answer 1

Here is the short answer: don't use SNAPSHOT dependencies between projects on your CI build. They are fine on your local machine, but CI environments tend to not work well**. There is a published algo for how SNAPSHOTs are resolved, but it's a mess. Instead, just use normal dependencies, and have a release job in your CI that produces releases.

Put another way, SNAPSHOTs should be considered essentially non-deterministic (at least from the point of view of a CI build agent).

The Versions plugin may be helpful for tracking dependencies.

** The only way I've seen it work consistently is if you set up a different repository for each build agent, and then wipe it out between each run. Drastic, horrible, inefficient and unneeded.