Stale SNAPSHOT Artifacts Resolved Despite Remote Repository Updates

Why the stale artifact appears

Maven decides whether to contact a remote repository for a SNAPSHOT based on the timestamp in the locally cached maven-metadata.xml and the updatePolicy for that repository. If the local metadata timestamp is still within the policy window (e.g., daily or a custom interval), Maven skips the remote HTTP request entirely. During this skip it does not verify the artifact’s checksum, even if the remote artifact has been redeployed with new content. Consequently a build can resolve an older cached SNAPSHOT while a newer version already exists on the server.

Confirmed facts

• updatePolicy is configured per <repository> (or <pluginRepository>) in settings.xml or the POM, not globally.
• Maven provides no built‑in CLI or API to invalidate a single cached SNAPSHOT; the standard ways are -U (force update all SNAPSHOTs) or manual deletion of the artifact directory under ~/.m2/repository.
• The checksum policy (<checksumPolicy>) only applies when Maven actually downloads the artifact; it is ignored when the timestamp policy says the cached metadata is fresh.

Steps to resolve the issue for this case

1. Scope the update policy to the snapshot repository only – edit settings.xml (or the POM) and set a short interval for the repository that hosts the SNAPSHOTs, leaving other repositories at a longer interval.

   <settings>
     <profiles>
       <profile>
         <id>snapshot‑profile</id>
         <activation>
           <activeByDefault>true</activeByDefault>
         </activation>
         <repositories>
           <repository>
             <id>internal-snapshots</id>
             <url>https://repo.example.com/snapshots</url>
             <releases>
               <enabled>false</enabled>
             </releases>
             <snapshots>
               <enabled>true</enabled>
               <updatePolicy>interval:30</updatePolicy> 
             </snapshots>
           </repository>
         </repositories>
       </profile>
     </profiles>
   </settings>

2. Validate that the remote repository updates maven-metadata.xml on each deployment – if your repository manager does not refresh the metadata timestamp, Maven will never see a change regardless of policy. Ask your admin: “Does the snapshot repository update the maven-metadata.xml timestamp whenever a new SNAPSHOT is deployed?” If the answer is no, fix the repository manager configuration first; otherwise proceed.
3. For CI environments where you need the absolute latest – keep the short interval (e.g., always or interval:1) only on the CI agent’s settings.xml. This limits extra traffic to CI builds while developer machines retain a reasonable interval.
4. If you must target a single artifact – use the maven-dependency-plugin to purge just that SNAPSHOT:

   mvn dependency:purge-local-repository \
     -DmanualInclude=com.example:my-artifact \
     -DreResolve=false

   This removes only the selected artifact’s version‑specific directory, forcing a fresh download on the next build.
5. Alternative: lock to a timestamped version – run the versions-maven-plugin to rewrite the POM with a timestamped SNAPSHOT (e.g., 1.0-20261019.123456-7) and commit that version. This guarantees reproducibility without relying on update policies.

   mvn versions:use-latest-snapshots -DprocessAllModules

When to ask for more detail

If your repository manager does not update the maven-metadata.xml timestamp on each SNAPSHOT deployment, the above policy changes will not help. In that case you need to adjust the repository manager’s deployment behavior before changing Maven settings.