skip to content

Snapshots & Deploy

2 roadmaps6 questions

SNAPSHOT semantics with timestamped remote artifacts, the deploy goal, and the distributionManagement targets it writes to. Interviewers ask so you can explain why overwriting a released version must be impossible.

on this pageshow

explore

questions

6

What does the maven-deploy-plugin's deploy goal do, and where does it sit in the build lifecycle relative to install?

level: juniorimportance: must knowfreq 65%

answer

  1. deploy = last default-lifecycle phase
  2. install = local ~/.m2 only
  3. deploy = remote, whole team
  4. uploads artifact+POM+checksums+metadata
  5. deploy:deploy-file for prebuilt jars

basics

~20 s

deploy is the last phase of the default lifecycle. The maven-deploy-plugin's deploy goal uploads the built artifact, its POM, and metadata to the remote repository. install (earlier) only copies it to your local ~/.m2 repo.

solid answer

~40 s

`deploy` is the final phase of Maven's default build lifecycle (...package, install, deploy). Running `mvn deploy` runs every phase up to and including it, then the maven-deploy-plugin's `deploy` goal uploads the artifact(s), the POM, checksums, and updates `maven-metadata.xml` in the configured remote repository (chosen from distributionManagement by version). Contrast with `install`, which only copies the artifact into your **local** repository (`~/.m2`) so other local projects can use it — nothing leaves your machine. So `install` = local sharing, `deploy` = team/public sharing. Deploy requires distributionManagement (and matching credentials in settings.xml); install does not. In CI, `deploy` is what publishes SNAPSHOTs continuously and releases at tag time.

code

bash · 5 lines
bash
# Build, test, package, install locally, then upload to remote
mvn deploy

# Skip publishing a particular module
mvn deploy -pl :aggregator -Dmaven.deploy.skip=true

go deeper

for a junior

Knows deploy uploads remotely and install is local-only, and deploy is the last phase.

for a middle

Lists what deploy uploads (artifact, POM, checksums, metadata) and uses deploy:deploy-file.

for a senior

Wires deploy into CI, skips non-publishable modules, and reasons about attached artifacts.

for a principal

Defines publish strategy: which lifecycle stage publishes SNAPSHOTs vs releases and how it integrates with release automation.

## The default lifecycle (relevant tail) Maven's *default* lifecycle is an ordered sequence of phases. The last few are: ``` ... -> test -> package -> verify -> install -> deploy ``` Running a phase runs **all preceding phases** too. So `mvn deploy` compiles, tests, packages, installs locally, then deploys. ## install vs deploy - **`install`** (maven-install-plugin) copies the built artifact + its POM into the **local** repository `~/.m2/repository`. This is purely local — useful so another project on the same machine can resolve it as a dependency. - **`deploy`** (maven-deploy-plugin) uploads to a **remote** repository so the **whole team / the world** can consume it. ## What deploy uploads The `deploy:deploy` goal publishes, for the target repo: - The main artifact (jar/war/etc.) and any attached artifacts (sources, javadoc, classifiers). - The effective POM (`.pom`). - Checksums (`.sha1`, `.md5`, and SHA-256/512 on modern repos). - Updated `maven-metadata.xml` (for SNAPSHOT timestamps or release version lists). The target repo is selected from `<distributionManagement>` based on whether the version is a SNAPSHOT. ## Requirements - `<distributionManagement>` must be present (else deploy errors). - Credentials in `settings.xml` matched by repository id. ## Useful invocations ```bash mvn deploy # full lifecycle then upload mvn deploy:deploy-file \ # deploy an arbitrary pre-built file -Dfile=app.jar -DgroupId=com.acme -DartifactId=app \ -Dversion=1.0.0 -Dpackaging=jar \ -DrepositoryId=company-releases -Durl=https://nexus.acme.com/... ``` `deploy:deploy-file` is handy for publishing a third-party jar that was never built by Maven. ## Skipping deploy Set `-Dmaven.deploy.skip=true` (or the plugin's `<skip>`) on modules you don't want published (e.g. an aggregator or a test fixtures module).

  • What is the difference between mvn install and mvn deploy?
    install copies the artifact to your local ~/.m2 repo only; deploy uploads it to the configured remote repository for the whole team.
  • How do you publish a jar that was not built by Maven?
    Use mvn deploy:deploy-file with -Dfile, the GAV coordinates, -Dpackaging, and -DrepositoryId/-Durl.

saying these in an interview costs you the question

  • Saying install uploads to the remote repository.
  • Claiming deploy runs before package.
  • Forgetting that deploy needs distributionManagement and credentials.

context

resolving links…

open as a page

What is the difference between a SNAPSHOT version and a release version in Maven, and how does Maven treat each one differently?

level: juniorimportance: must knowfreq 80%

basics

~10 s

A SNAPSHOT (e.g. 1.0.0-SNAPSHOT) is an in-development, mutable version Maven re-checks and may re-download; a release (e.g. 1.0.0) is final and immutable, downloaded once and cached forever.

open as a page

How do you configure where Maven deploys artifacts, and how does it choose between the release and snapshot repositories?

level: middleimportance: must knowfreq 60%

basics

~10 s

You add <distributionManagement> to the POM with <repository> (for releases) and <snapshotRepository> (for SNAPSHOTs). Maven picks based on the version: -SNAPSHOT versions go to snapshotRepository, all others go to repository.

open as a page

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%

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.

open as a page

Why does re-deploying the same release version usually fail, but re-deploying a SNAPSHOT succeeds? How would you design a release process around that?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Repository managers enforce release immutability: a release version can be published only once, so re-deploy is rejected. SNAPSHOTs are mutable, so each deploy adds a new timestamped build. To fix a release you publish a new version.

open as a page

How do the <repositories> used for downloading dependencies differ from <distributionManagement> and the snapshot/release update policies that govern resolution?

level: seniorimportance: should knowfreq 35%

basics

~10 s

<repositories> tells Maven where to download dependencies from; <distributionManagement> tells it where to upload your build. Each download repo can enable/disable <releases> and <snapshots> and set per-policy <updatePolicy> and <checksumPolicy>.

open as a page