skip to content

When you deploy a SNAPSHOT to a remote repository, what actually gets stored there, and how does that differ from the file in your local repository?

level: middleimportance: should knowfreq 50%

answer

  1. remote = timestamped + buildNumber
  2. local = single -SNAPSHOT file
  3. maven-metadata.xml indexes latest
  4. yyyyMMdd.HHmmss-N pattern, UTC
  5. uniqueVersion forced true in Maven 3

basics

~10 s

Remotely, each SNAPSHOT deploy is stored as a unique timestamped file (e.g. myapp-1.0.0-20260621.101500-3.jar) plus maven-metadata.xml that points to the latest; locally Maven just keeps a single myapp-1.0.0-SNAPSHOT.jar.

solid answer

~40 s

Locally, a SNAPSHOT lives under a simple name like `myapp-1.0.0-SNAPSHOT.jar`. But when deployed to a remote repo with `uniqueVersion` behavior (the default and only mode in Maven 3+), each deploy produces a uniquely *timestamped* artifact such as `myapp-1.0.0-20260621.101500-3.jar`, where `20260621.101500` is the UTC timestamp and `3` is the build number. A `maven-metadata.xml` file in the SNAPSHOT directory records the latest timestamp/buildNumber so consumers can resolve `-SNAPSHOT` to the newest concrete artifact. This means the remote keeps a history of SNAPSHOT builds (until cleanup policy purges old ones), enabling rollback and avoiding the corruption that the old non-unique mode caused. Consumers still reference `1.0.0-SNAPSHOT`; Maven reads the metadata and downloads the right timestamped file.

code

xml · 14 lines
xml
<!-- maven-metadata.xml snippet in a remote SNAPSHOT dir -->
<versioning>
  <snapshot>
    <timestamp>20260621.101500</timestamp>
    <buildNumber>3</buildNumber>
  </snapshot>
  <snapshotVersions>
    <snapshotVersion>
      <extension>jar</extension>
      <value>1.0.0-20260621.101500-3</value>
      <updated>20260621101500</updated>
    </snapshotVersion>
  </snapshotVersions>
</versioning>

go deeper

for a junior

Knows the local repo holds one -SNAPSHOT file per version.

for a middle

Explains remote timestamped artifacts, the filename pattern, and maven-metadata.xml's role.

for a senior

Discusses why unique versions exist (concurrency, rollback) and SNAPSHOT retention/cleanup trade-offs.

for a principal

Designs repo-manager retention policies and storage governance across many SNAPSHOT-publishing teams.

## Local vs remote SNAPSHOT layout When you build a SNAPSHOT locally, the artifact is written to your local repo (`~/.m2/repository`) under a plain name: ``` ~/.m2/repository/com/acme/myapp/1.0.0-SNAPSHOT/myapp-1.0.0-SNAPSHOT.jar ``` There is only ever **one** copy locally — each build overwrites the previous. ## What deploy stores remotely Running `mvn deploy` against a remote SNAPSHOT repository stores a **uniquely timestamped** artifact: ``` com/acme/myapp/1.0.0-SNAPSHOT/ myapp-1.0.0-20260621.101500-1.jar myapp-1.0.0-20260621.143012-2.jar myapp-1.0.0-20260622.090044-3.jar maven-metadata.xml ``` The filename pattern is `artifactId-baseVersion-yyyyMMdd.HHmmss-buildNumber`. The timestamp is **UTC**; the build number increments per deploy. ## maven-metadata.xml This file is the index. It contains a `<snapshot>` block with the latest `<timestamp>` and `<buildNumber>`, plus a `<snapshotVersions>` list mapping each classifier/extension to its concrete timestamped value. When a consumer resolves `1.0.0-SNAPSHOT`, Maven downloads this metadata first, finds the newest timestamped artifact, and fetches that. ## uniqueVersion In Maven 2 you could set `<uniqueVersion>false</uniqueVersion>` to store SNAPSHOTs under the plain `-SNAPSHOT` name remotely (overwriting each time). **Maven 3+ ignores this and always uses unique timestamps** — non-unique mode was removed because concurrent deploys corrupted artifacts. ## Why timestamps help - **History/rollback:** old SNAPSHOT builds remain available. - **Concurrency-safe:** parallel deploys do not clobber each other. - **Reproducibility within a window:** CI can pin an exact timestamped SNAPSHOT if needed. The trade-off is storage growth, which repository managers handle with SNAPSHOT cleanup/retention policies (e.g. keep last N or last X days).

  • How does a consumer of 1.0.0-SNAPSHOT pick the right timestamped jar?
    Maven downloads maven-metadata.xml from the snapshot repo, reads the latest timestamp/buildNumber, and resolves to that concrete timestamped artifact.
  • What happened to <uniqueVersion>false</uniqueVersion>?
    It worked in Maven 2 to store non-timestamped SNAPSHOTs, but Maven 3+ ignores it and always uses unique timestamps to avoid concurrency corruption.

saying these in an interview costs you the question

  • Claiming remote SNAPSHOTs overwrite the same file like the local repo does.
  • Saying you can still disable timestamping with uniqueVersion=false in Maven 3.
  • Thinking the timestamp is local time rather than UTC.

context

resolving links…