skip to content

Walk through what maven-deploy-plugin does at the deploy phase, and how SNAPSHOT versions are handled differently from releases.

level: seniorimportance: should knowfreq 40%

answer

  1. deploy → remote repo, distributionManagement
  2. SNAPSHOT = mutable, timestamped, snapshotRepository
  3. release = immutable, repo rejects overwrite
  4. credentials via settings.xml <server> id match
  5. uploads pom + sources + javadoc + checksums

basics

~10 s

deploy uploads the artifact and POM to a remote repository. SNAPSHOT versions go to the snapshots repo and can be re-deployed (overwritten with timestamps); release versions go to the releases repo and are immutable.

solid answer

~40 s

At the `deploy` phase, maven-deploy-plugin uploads the primary artifact, the POM, attached artifacts (sources/javadoc), and checksums to the repository chosen in `<distributionManagement>`. The choice between the `<repository>` (releases) and `<snapshotRepository>` (snapshots) elements is driven by whether the version ends in `-SNAPSHOT`. SNAPSHOTs are mutable: each deploy publishes a new timestamped build (e.g. `1.0-20260101.120000-3.jar`) and updates `maven-metadata.xml`; consumers resolving `1.0-SNAPSHOT` get the latest. Releases are immutable: most repository managers reject re-deploying the same release version, which guarantees reproducibility. Credentials come from a matching `<server>` in `settings.xml` keyed by the repo `id`. This is why CI deploys SNAPSHOTs on every merge and only deploys releases during a controlled release process.

code

xml · 10 lines
xml
<distributionManagement>
  <repository>
    <id>releases</id>
    <url>https://nexus.example.com/repository/maven-releases/</url>
  </repository>
  <snapshotRepository>
    <id>snapshots</id>
    <url>https://nexus.example.com/repository/maven-snapshots/</url>
  </snapshotRepository>
</distributionManagement>

go deeper

for a junior

Know deploy pushes to a remote repo and SNAPSHOT means in-development.

for a middle

Explain distributionManagement repository vs snapshotRepository selection by version suffix.

for a senior

Reason about mutability, reproducibility, timestamped snapshots, and credential handling in CI.

for a principal

Design the org's release strategy, immutability policies, repo manager governance, and supply-chain integrity (checksums/signing).

## What deploy uploads The `deploy` goal (bound to the `deploy` phase) pushes to a **remote repository** so the artifact is shareable across machines and teams. It uploads: - the primary artifact (jar/war/...), - the `pom.xml`, - any **attached** artifacts (e.g. `-sources.jar`, `-javadoc.jar`), - `.sha1`/`.md5` (and increasingly `.sha256`) checksums, - and updates `maven-metadata.xml` (version lists / latest snapshot timestamp). ## Where it uploads — distributionManagement ```xml <distributionManagement> <repository> <id>releases</id> <url>https://nexus.example.com/repository/maven-releases/</url> </repository> <snapshotRepository> <id>snapshots</id> <url>https://nexus.example.com/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement> ``` Maven picks `<snapshotRepository>` when the project version ends with `-SNAPSHOT`, otherwise `<repository>`. ## SNAPSHOT vs release semantics - **SNAPSHOT** (`1.4.0-SNAPSHOT`) = an in-development, *mutable* version. Each deploy creates a uniquely **timestamped** file (`1.4.0-20260620.101500-7.jar`) and bumps the build number in metadata. Anyone depending on `1.4.0-SNAPSHOT` will fetch the newest one (subject to their `<updatePolicy>`). Designed for rapid iteration. - **Release** (`1.4.0`) = *immutable*. Repo managers like Nexus/Artifactory normally **forbid overwriting** an existing release. This guarantees a given coordinate always means the same bytes — the foundation of reproducible builds. ## Credentials The upload authenticates using a `<server>` block in `~/.m2/settings.xml` whose `<id>` matches the repo `<id>` in distributionManagement: ```xml <servers> <server> <id>snapshots</id> <username>ci</username> <password>${env.NEXUS_TOKEN}</password> </server> </servers> ``` ## CI implications - Every merge to main can `mvn deploy` a SNAPSHOT so downstream teams test against latest. - Releases use a deliberate flow (often maven-release-plugin or a tag pipeline) that strips `-SNAPSHOT`, deploys an immutable version, then bumps to the next SNAPSHOT. - `deploy:deploy-file` can publish a prebuilt artifact without a full build (e.g. third-party jars).

  • Why are release versions immutable but SNAPSHOTs mutable?
    Immutable releases guarantee reproducibility — a coordinate always resolves to the same bytes. SNAPSHOTs are mutable so teams can iterate rapidly and always pull the latest in-development build.
  • Where do deploy credentials come from?
    From a <server> entry in settings.xml whose id matches the repository id in distributionManagement; the password is often an env-injected token.
  • What is the timestamp like 20260620.101500-7 in a snapshot filename?
    It is the unique build identifier (UTC timestamp + build number) that lets the snapshot repo keep multiple distinct uploads of the same -SNAPSHOT version.

SNAPSHOT is like a shared Google Doc that keeps changing under the same link; a release is a printed, numbered book edition that can never be altered.

saying these in an interview costs you the question

  • Saying SNAPSHOT and release behave identically in the repo.
  • Believing release versions can be freely re-deployed/overwritten.
  • Putting credentials in distributionManagement instead of settings.xml <server>.

context

resolving links…