Among users of Maven there is a huge tendency, which is difficult to influence. The tendency is to break down projects into a number of independently releasable sub-projects, but to keep on working at all of the sub-projects at the same time. In this case using fixed versions of dependencies does not work at all – you don’t see fresh changes at all; using dependencies on SNAPSHOTs is ok (although it requires everyone to have these snapshots in local maven repository or publishing snapshots to Nexus snapshots repository) until release time comes.
However large number of projects decide to use version ranges for their dependencies, which they still release occasionally during development and more frequently by the time of the release. These projects expect to use the latest version of dependencies regardless of if it’s a snapshot or a released version. However release build fails if a version range gets resolved to a snapshot.
Therefore we had to introduce pre-build step, which purges all versions of dependencies from local maven repository and therefore forces build to resolved released versions from Nexus. Taking into account multiple build executors on the same machine, it’s not a full-prove solution, but it works (relatively) good for projects, which do not publish their SNAPSHOTs to Nexus. Although I believe it’s very dangerous, release builds of these projects use different Nexus group repository, which excludes repository with snapshots, and a separated local maven repository… it works until you forget to release dependencies with last-minute fixes before releasing the main project.
These are all work-arounds the tendency to break down projects too early. I truly believe every independently releasable project should use only fixed versions of dependencies. If it requires too frequent releases of dependencies, then they are not stable enough and together with their dependants they should form a multi-module project with a single set of builds.