skip to content

How do per-repository <releases> and <snapshots> policies control updatePolicy and checksumPolicy?

level: seniorimportance: should knowfreq 45%

answer

  1. <releases> vs <snapshots> blocks
  2. enabled / updatePolicy / checksumPolicy
  3. updatePolicy: always|daily|interval:N|never
  4. checksumPolicy: warn|fail|ignore
  5. mvn -U overrides updatePolicy

basics

~10 s

Each <repository> can have separate <releases> and <snapshots> blocks. Each can be enabled/disabled and set updatePolicy (how often to re-check, e.g. daily/always/never/interval) and checksumPolicy (warn/fail/ignore on checksum mismatch).

solid answer

~40 s

A `<repository>` (or `<pluginRepository>`) declares two policy blocks: `<releases>` and `<snapshots>`. Each holds `<enabled>` (whether that artifact class is fetched from this repo), `<updatePolicy>`, and `<checksumPolicy>`. `updatePolicy` governs how often Maven re-checks for updated **snapshot** metadata: `always`, `daily` (default), `interval:<minutes>`, or `never`. Releases are immutable so their updatePolicy mainly affects metadata. `checksumPolicy` decides behaviour when a downloaded artifact's checksum doesn't match: `warn` (default — log and continue), `fail` (abort the build), or `ignore`. A typical split enables only releases on a stable repo and only snapshots on a snapshot repo, sets `failOnError`-style `fail` checksums for security, and uses `always`/short interval for snapshots in CI. Note that `mvn -U` forces an update check regardless of updatePolicy.

code

xml · 13 lines
xml
<repository>
  <id>corp-nexus</id>
  <url>https://nexus.corp.example/repository/maven-public/</url>
  <releases>
    <enabled>true</enabled>
    <checksumPolicy>fail</checksumPolicy>
  </releases>
  <snapshots>
    <enabled>true</enabled>
    <updatePolicy>always</updatePolicy>
    <checksumPolicy>warn</checksumPolicy>
  </snapshots>
</repository>

go deeper

for a junior

Knows repos have separate releases and snapshots settings.

for a middle

Knows updatePolicy values and checksumPolicy values and their defaults.

for a senior

Tunes per-repo policies for CI vs local, uses fail checksums, and knows -U overrides updatePolicy.

for a principal

Sets org-wide policy defaults (security checksums, snapshot freshness) and reasons about cache/integrity trade-offs.

## Why two policy blocks Maven treats two artifact classes differently: - **Releases** (e.g. `1.2.0`) are **immutable** — once published they never change. - **Snapshots** (e.g. `1.2.0-SNAPSHOT`) are **mutable** work-in-progress — they get overwritten as development proceeds. So each `<repository>` lets you configure them separately via `<releases>` and `<snapshots>`. ## The three settings in each block ```xml <repository> <id>corp-nexus</id> <url>https://nexus.corp.example/repository/maven-public/</url> <releases> <enabled>true</enabled> <updatePolicy>daily</updatePolicy> <checksumPolicy>fail</checksumPolicy> </releases> <snapshots> <enabled>true</enabled> <updatePolicy>always</updatePolicy> <checksumPolicy>warn</checksumPolicy> </snapshots> </repository> ``` ### enabled `true`/`false`. If `false`, Maven won't look for that artifact class here. Best practice: a *releases* repo enables releases only; a *snapshots* repo enables snapshots only. This stops Maven from making useless 404 round-trips. ### updatePolicy (how often to re-check) Controls how often Maven re-downloads **metadata** (`maven-metadata.xml`) to discover newer versions/timestamps: - `always` — every build. - `daily` — once per day (the **default**). - `interval:N` — every N minutes. - `never` — only if absent locally. Most relevant for **snapshots**, where new timestamped builds appear constantly. Releases are immutable so updatePolicy mostly affects how often release metadata (latest version) is refreshed. ### checksumPolicy (integrity on mismatch) Maven downloads `.sha1`/`.md5` alongside each artifact. If the computed checksum disagrees: - `warn` — log a warning and proceed (**default**). - `fail` — abort the build (use this for supply-chain safety). - `ignore` — say nothing. ## Forcing updates `mvn -U` (`--update-snapshots`) forces Maven to check remote for newer snapshots and missing releases this run, **overriding** `updatePolicy`. Deleting `~/.m2/repository/...` or the `_remote.repositories`/`*.lastUpdated` markers also forces re-resolution. ## Where these policies live They are declared on `<repository>`/`<pluginRepository>` in the pom (or in a `<profile>` in settings.xml). They are **per repository**, so a mirror does not change them — the original repo's policies still apply even though traffic is redirected to the mirror. ## Practical recommendations - Disable snapshots on release-only repos and vice-versa. - `checksumPolicy=fail` for security-sensitive builds. - `updatePolicy=always` (or short interval) for CI snapshot consumers; `daily`/`never` locally to cut latency.

  • What is the default updatePolicy and checksumPolicy?
    updatePolicy defaults to daily; checksumPolicy defaults to warn.
  • How do you force Maven to re-check snapshots regardless of updatePolicy?
    Run with -U / --update-snapshots, which overrides updatePolicy for that build.
  • Why disable snapshots on a release repository?
    It avoids pointless metadata/404 lookups for -SNAPSHOT artifacts that the repo will never host.

saying these in an interview costs you the question

  • Claiming updatePolicy re-downloads release artifacts (releases are immutable — it affects metadata/snapshots)
  • Thinking checksumPolicy=fail is the default
  • Believing a mirror overrides the original repo's release/snapshot policies

context

resolving links…