Why Your Maven SNAPSHOT Isn’t Updating and How to Fix It

Scenario 1: SNAPSHOT version is not the latest

Symptoms

After pushing 1.0.0‑SNAPSHOT, teammates still retrieve an older artifact.

Investigation points

Push side : Nexus metadata may not have been updated.

Transfer side : Maven’s update policy may not have triggered a check.

Receive side : Local repository may still cache the old artifact.

Resolution steps

Verify Nexus metadata

curl -s "http://your-nexus/repository/snapshots/com/yourcompany/your-artifact/1.0.0-SNAPSHOT/maven-metadata.xml"

Check the <lastUpdated> and <snapshotVersions> timestamps.

Inspect local cache

ls -la ~/.m2/repository/com/yourcompany/your-artifact/1.0.0-SNAPSHOT/

Verify the JAR modification time, the _remote.repositories file (source repository) and resolver-status.properties (last remote check).

Force update mvn clean install -U If the problem persists, delete the cached directory and reinstall:

rm -rf ~/.m2/repository/com/yourcompany/your-artifact/1.0.0-SNAPSHOT
mvn clean install

updatePolicy configuration

In settings.xml or pom.xml repository definitions, updatePolicy controls SNAPSHOT checks: always – check on every build. daily – check only on the first build of the day (default). interval:X – check every X minutes. never – never check.

Nexus metadata refresh

curl -X POST -u admin:password "http://your-nexus/service/rest/v1/repositories/snapshots/rebuild-index"

Scenario 2: Dependency cannot be resolved

Symptoms

Could not find artifact com.yourcompany:common-util:jar:1.0.0 in nexus (http://your-nexus/repository/public)

Resolution steps

Confirm artifact exists on Nexus

curl -I "http://your-nexus/repository/releases/com/yourcompany/common-util/1.0.0/common-util-1.0.0.jar"

HTTP 200 indicates presence; 404 means missing.

Check settings.xml repository configuration Common pitfalls:

Mirror configuration intercepts the request.

Repository element is missing or mis‑configured.

Profile containing the repository is not activated.

<mirror>
  <id>nexus</id>
  <mirrorOf>*</mirrorOf>
  <url>http://your-nexus/repository/public</url>
</mirror>

Enable debug logging to see the exact URL Maven contacts

mvn clean install -X 2>&1 | grep -A5 "Downloading from"

Scenario 3: Resolved version differs from declared version

Symptoms

The pom.xml declares 1.2.0, but Maven resolves 1.1.0.

Investigation steps

Inspect dependency tree

mvn dependency:tree -Dincludes=com.yourcompany:common-util

Shows which path brings in the conflicting version.

View effective POM

mvn help:effective-pom | grep -A10 "common-util"

Reveals the final version after inheritance and imports.

Maven version mediation rules

Nearest definition wins (shortest dependency path). Example:

A → B → C → X:1.0
A → D → X:2.0

Result: X:2.0 wins.

First declaration wins when paths are of equal length; order in pom.xml decides.

dependencyManagement overrides all ; any version locked there is used regardless of path length.

Common pitfalls

Parent POM’s dependencyManagement overrides child declarations.

BOM imports ( scope=import) can supersede explicit versions; the first declared BOM wins.

Exclusions may be overridden by another path that re‑introduces the dependency.

Scenario 4: Works locally but others cannot pull

Possible reasons:

Deploy command failed (network glitch, permission issue, disk full).

Local repository still contains the artifact, giving a false impression of success.

Artifact was deployed to the wrong repository (e.g., test repo instead of release repo).

Self‑check procedure

# Clear local cache
rm -rf ~/.m2/repository/com/yourcompany/your-artifact/1.0.0-SNAPSHOT

# Attempt to pull from Nexus
mvn dependency:get -Dartifact=com.yourcompany:your-artifact:1.0.0-SNAPSHOT

# Direct curl verification
curl -I "http://your-nexus/repository/snapshots/com/yourcompany/your-artifact/1.0.0-SNAPSHOT/your-artifact-1.0.0-SNAPSHOT.jar"

If the artifact cannot be retrieved, the deploy step did not succeed.

Final troubleshooting checklist

Identify whether the problem originates on the Nexus side or the client side.

Push‑side checks : deployment errors, distributionManagement URL, server credentials, and whether all modules (parent POM, sub‑modules, BOM) were deployed.

Pull‑side checks : repository configuration in settings.xml, mirror interception, profile activation, updatePolicy, and local cache cleanup.

Version conflict checks : mvn dependency:tree -Dincludes=…, mvn help:effective-pom, parent dependencyManagement, BOM imports.

Common commands quick reference

# Force SNAPSHOT update
mvn clean install -U

# Show dependency tree (filter)
mvn dependency:tree -Dincludes=groupId:artifactId

# Show full conflict resolution
mvn dependency:tree -Dverbose

# Show effective POM
mvn help:effective-pom

# Show effective settings
mvn help:effective-settings

# List active profiles
mvn help:active-profiles

# Analyze unused/undeclared dependencies
mvn dependency:analyze

# Download a single artifact for testing
mvn dependency:get -Dartifact=groupId:artifactId:version

# Remove a specific artifact from local repo
rm -rf ~/.m2/repository/com/yourcompany/artifact-name

# Enable debug logging
mvn clean install -X