Stale SNAPSHOT Artifacts Resolved Despite Remote Repository Updates

Cache Freshness vs. Build Reproducibility

Maven's local repository caches SNAPSHOT dependencies according to the updatePolicy interval defined in settings.xml or the POM. The default daily interval means a remote SNAPSHOT artifact can be rebuilt and deployed multiple times before Maven rechecks the repository. This creates a window where builds resolve a stale cached version instead of the latest deployed artifact.

The tension centers on the maven-metadata.xml timestamp comparison that Maven performs during resolution. When the local metadata timestamp falls within the update policy window, Maven skips the remote check entirely, even if the remote artifact's checksum has changed. This behavior is by design for performance, but it introduces non-determinism across developer machines and CI agents that may have cached different SNAPSHOT builds.

Teams relying on frequent SNAPSHOT deployments need a reliable mechanism to ensure resolution consistency without globally disabling caching via -U, which degrades build performance and increases repository load.

Open Questions

1. Can the updatePolicy be scoped to specific repositories or dependencies rather than applied globally?
2. Does Maven provide a programmatic way to invalidate a single cached SNAPSHOT without a full -U refresh?
3. How does the checksum verification interact with the timestamp-based update policy when the remote artifact changes but the metadata timestamp does not?