Maven Force Update Snapshot Dependencies

Question

Here is the result of mvn -version:

Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800)
Maven home: /usr/share/maven
Java version: 1.7.0_67, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.5", arch: "x86_64", family: "mac"

Suppose I have a snapshot dependency:

<dependency>
    <groupId>org.puzzled</groupId>
    <artifactId>foo</artifactId>
    <version>1.0.4-SNAPSHOT</version>
</dependency>

I have a downloaded copy of that snapshot in my local repo. But then other developers have made improvements and there is an update to the foo-1.0.4-SNAPSHOT.jar. I want to issue Maven an executive order to update that dependency by downloading it from a remote repository.

According to the response to this and many other questions on SO, if I do

mvn clean -U package

it should just (re)download all the dependencies. Right? That is not what happens. It downloads metadata for snapshot dependencies, deduces (and wrongly, at that) that no updating is required. I have to delete the associated subdirectory in my local .m2 repository for Maven to update a snapshot release from the remote repo, even with the -U flag.

Is this a bug, or am I missing something?

Answer 1

mvn clean install -U

-U means force update of dependencies.

Answer 2

Is it possible that the repository is publishing your foo using a non-unique SNAPSHOT name?

This blog entry explains nicely the difference between a unique and non-unique SNAPSHOT artifact.

Essentially, it's non-unique if the artifact metadata appears on nexus as foo-1.0.4-SNAPSHOT.jar. It's unique if it appears as foo-1.0.4-20160122.172609-36.jar.

You can only publish unique snapshot artifacts in Maven 3, but still resolve old timestamped non-unique snapshots... but it's pretty iffy. Taking a look at the ancient doc, it seems that there's some unclear and vague interaction between the filesystem date, and the metadata.xml on both local and remote machines.

Essentially: (1) Try to make sure that your SNAPSHOT dependencies are published with unique artifacts, and (2) if they aren't, don't depend on new SNAPSHOTs being detected. Use mvn dependency:purge-local-repository with appropriate includes to remove the old SNAPSHOTs from your local m2 instead.