skip to content

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%

answer

  1. <repositories> download, distributionManagement upload
  2. <releases>/<snapshots> enable + updatePolicy
  3. updatePolicy: always/daily/never/interval:N
  4. checksumPolicy: fail/warn/ignore
  5. mirrorOf=* funnels through repo manager

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>.

solid answer

~40 s

Resolution and publishing are configured separately. `<repositories>` (in the POM or, better, a mirror/profile in settings.xml) lists sources Maven *downloads* dependencies from. Each entry has `<releases>` and `<snapshots>` blocks where you set `<enabled>` and an `<updatePolicy>` (always/daily/never/interval:N) plus `<checksumPolicy>` (warn/fail/ignore). A typical setup enables snapshots only on the snapshot repo and releases only on the release repo, so Maven doesn't waste round-trips. `<distributionManagement>` is the opposite direction: it names where `mvn deploy` *uploads* releases vs SNAPSHOTs. In practice you front everything with a single repository-manager group/mirror via settings.xml `<mirrorOf>*</mirrorOf>`, so developers resolve through one URL while the manager aggregates upstreams. The updatePolicy is what makes `-U` meaningful and controls how fresh your SNAPSHOT dependencies are.

code

xml · 6 lines
xml
<repository>
  <id>company</id>
  <url>https://nexus.acme.com/repository/maven-public/</url>
  <releases><enabled>true</enabled><updatePolicy>daily</updatePolicy></releases>
  <snapshots><enabled>true</enabled><updatePolicy>always</updatePolicy></snapshots>
</repository>

go deeper

for a junior

Knows <repositories> is for downloading and distributionManagement is for uploading.

for a middle

Explains <releases>/<snapshots> enabling and the updatePolicy values including -U.

for a senior

Tunes updatePolicy/checksumPolicy for CI vs dev and uses a mirror/repo-manager group.

for a principal

Architects the org's repository topology: mirror policy, proxy/group repos, allowlists, and SNAPSHOT freshness governance.

## Two opposite directions - **Download (resolution):** `<repositories>` and `<pluginRepositories>` — where Maven fetches dependencies/plugins **from**. - **Upload (publishing):** `<distributionManagement>` — where `mvn deploy` pushes your artifacts **to**. They are independent; mixing them up is a common interview slip. ## Anatomy of a download repository ```xml <repositories> <repository> <id>company</id> <url>https://nexus.acme.com/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> </repositories> ``` - `<enabled>` — whether this repo serves releases / snapshots at all. - `<updatePolicy>` — how often to re-check for updates: `always`, `daily` (default), `never`, `interval:N` (minutes). Only meaningful for SNAPSHOTs (and for metadata of releases); a cached release is never re-downloaded regardless. - `<checksumPolicy>` — `fail`, `warn` (default), or `ignore` on checksum mismatch. ## The -U flag `mvn -U` (`--update-snapshots`) forces an immediate update check this run, overriding `updatePolicy` (effectively `always` for this invocation). It does **not** make Maven re-download release versions. ## Repository manager and mirrors In real organizations you usually do **not** list many repos in each POM. Instead, settings.xml defines a **mirror** that redirects all resolution through one repository-manager URL: ```xml <mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>https://nexus.acme.com/repository/maven-public/</url> </mirror> ``` The manager aggregates Maven Central + internal release + internal snapshot repos into one group, giving a single, cacheable, governable entry point. ## How this ties to SNAPSHOT freshness Because SNAPSHOT dependencies are mutable, the download repo's `<snapshots><updatePolicy>` decides how stale your transitive SNAPSHOT deps can get. CI often uses `-U` to guarantee the latest, while local dev keeps `daily` for speed. ## Summary table - Want a dependency? -> resolved via `<repositories>`/mirror, governed by updatePolicy. - Want to publish? -> uploaded via `<distributionManagement>` (repository vs snapshotRepository).

  • Does updatePolicy affect release versions?
    Not for already-cached release artifacts (they're immutable and never re-fetched). It mainly governs SNAPSHOT update checks and metadata refresh frequency.
  • Why front everything with a mirrorOf=* repository manager?
    It gives one governable, cacheable entry point, aggregates Central plus internal release/snapshot repos, speeds builds, and lets you control/audit what dependencies are allowed.

saying these in an interview costs you the question

  • Treating <repositories> and <distributionManagement> as interchangeable.
  • Claiming updatePolicy or -U re-downloads cached release versions.
  • Saying you must list every upstream repo in each project POM rather than using a mirror.

context

resolving links…