We're using Maven and Nexus to distribute components (Maven projects) inside our infrastructure. For the sake of the argument, let's say we have two teams: Team Foo and Team Bar; and that a component from Bar depends on a component from Foo.
Team Bar wants to write contract tests for checking if component foo
behaves as expected. Those tests would run every night against the latest stable development version of project foo
(git master after CI). Could Team Bar write a Maven project bar/pom.xml
that depends on the latest version of foo
? How can we go about doing that?
We're playing with the idea of solving this through version naming. We would always name the under development version as master-SNAPSHOT
(or something) and instead of the version label going 0.1-SNAPSHOT -> 0.1 -> 0.2-SNAPSHOT -> 0.2
, it would always go back to master-SNAPSHOT
, like master-SNAPSHOT -> 0.1 -> master-SNAPSHOT -> 0.2
. Contract testing project bar
could then declare its dependency to foo
as com.acme:foo:master-SNAPSHOT
.
But this seems too clunky (breaks common Maven practice and stuff)... Is there a more standard practice for this kind of thing? Should we use Maven Versions Plugin? Should we inject the latest version string into the Maven project from the outside? Or maybe ditch Maven altogether?
A contract test module usually has a very strong relationship to the module implementing the contract.
Thus, I recommend to evolve both modules alongside each other within a parent project.
Make
foo
andbar
modules of a multi-module maven project. Then makebar
depend onfoo
like you suggested yourself. Assign both the same version${parent.version}
. This implies you use${parent.version}-SNAPSHOT
in between releases.Keep evolving and releasing your project like you would with a single module, preferably by using the
maven-release-plugin
on release. It will raise the versions of all modules concurrently as part of therelease:prepare
goal.