A: 

It looks like you posted the wrong maven-metadata from Nexus, this looks like the one in the acme folder rather than the acme/1.0-SNAPSHOT folder. (it would have the build number and timestamp in there).

Anyway, have you tried adding -U to the maven build commands? It's possible that you've stumbled upon some maven bug respecting the always setting, but I'm sure -U works.

Brian Fox
Thanks for your attention on my issue, Brian. I managed to track down the root cause which I explain in my answer. If there's something I'm missing, please let me know.
Brian Laframboise
A: 

It took me a while, but I tracked down the underlying issue to maven bug MNG-4142.

Here's what happened:

My acme-1.0-SNAPSHOT (build 1) was installed on A and uploaded to Nexus. The project was next built on B where the newly built acme-1.0-SNAPSHOT (build 2) was installed and uploaded to Nexus, overriding build 1.

Then, when a build happened on the A machine that had acme-1.0-SNAPSHOT as a dependency, MNG-4142 kicked in. The repository metadata contained "true" which prevented A from downloading the more recent build 2 of acme-1.0-SNAPSHOT, and so maven built my project against the older build 1 which caused build failures. This was still the case even when -U was used.

As I mentioned on the issue, I'm quite surprised at this behaviour and struggle to think of how other distributed build environments work in the presence of this bug. We currently have some cron jobs that frequently change the "localCopy" metadata to false in order to get what I believe should be the default, and correct, behaviour.

Brian Laframboise