skip to content

Walk me through the order in which Maven resolves an artifact across local and remote repositories.

level: middleimportance: must knowfreq 60%

answer

  1. local first, then remotes
  2. declaration order, first wins
  3. release immutable / snapshot polls
  4. updatePolicy daily, -U forces
  5. negative cache .lastUpdated

basics

~20 s

Maven first looks in the local repository (~/.m2). If the artifact isn't there, it tries the configured remote repositories in order; the first one that has it wins, and the file is cached locally so next time it comes from local.

solid answer

~40 s

Resolution is local-first: Maven checks `~/.m2/repository` for the exact GAV. A hit means no network call. On a miss, it queries the remote repositories — those inherited from the Super POM (`central`) plus any declared in the POM or active profiles, in declaration order — and the first repo that serves the artifact wins; it's then cached locally. Mirrors short-circuit this: if a `<mirror>` matches a repo id, requests go to the mirror URL instead. For **release** versions, once cached, Maven won't re-check remotes. For **SNAPSHOT** versions, Maven consults `maven-metadata.xml` and the configured `<snapshots><updatePolicy>` (default `daily`) to decide whether to look for a newer timestamped build. A failed lookup can be cached as a negative result; `-U` (`--update-snapshots`) forces a re-check. Offline mode (`-o`) skips remotes entirely and uses only the local cache.

code

bash · 3 lines
bash
mvn dependency:resolve      # local then remotes
mvn -U clean install        # force re-check SNAPSHOTs
mvn -o clean install        # offline: local cache only

go deeper

for a junior

Local cache first, then remote download.

for a middle

Explain declaration order, first-wins, and release vs snapshot update policies.

for a senior

Diagnose stale snapshots, negative caching, and mirror precedence in real builds.

for a principal

Design repository ordering/mirroring strategy and reproducibility guarantees across the org.

## The core rule: local first For any needed artifact (identified by GAV), Maven asks: is it already in the **local repository** (`~/.m2/repository`)? If yes, use it — no network. If no, go remote. ## Remote lookup order The set of remote repositories is the union of: 1. `central` (from the inherited Super POM). 2. Any `<repositories>` declared in your POM or in active `<profiles>`. Maven tries them in **declaration order**. The **first** repository that has the artifact wins; Maven downloads it, verifies checksums, and writes it into the local repo. Mirrors override this: a matching `<mirror>` (`mirrorOf` = repo id, `*`, etc.) replaces the original URL. ## Release vs SNAPSHOT behaviour - **Release** (e.g. `1.4.0`): immutable. Once in the local cache, Maven never re-downloads it. - **SNAPSHOT** (e.g. `1.4.0-SNAPSHOT`): mutable, expected to change. Maven reads `maven-metadata.xml` to find the latest timestamped build and respects the repository's `<snapshots><updatePolicy>` (`daily` by default, also `always`, `never`, or `interval:NN`). `-U`/`--update-snapshots` forces an immediate re-check. ## Negative caching If an artifact isn't found, Maven may remember the failure (a `*.lastUpdated` marker) and not retry until the update policy permits, to avoid hammering servers. `-U` clears this for snapshots. ## Offline mode `mvn -o` (`--offline`) tells Maven to never touch remotes — it resolves purely from the local cache. Missing artifacts then fail the build rather than triggering a download. ```bash # Normal resolution (local -> remotes) mvn dependency:resolve # Force re-checking snapshots against remotes mvn -U clean install # Build using only the local cache mvn -o clean install ``` ## Why this matters Understanding the order explains common confusion: "I deleted the JAR from Nexus but my build still works" (it's cached locally), or "my snapshot won't update" (update policy + missing `-U`).

  • Your colleague pushed a new SNAPSHOT but your build keeps the old one — why and how do you fix it?
    The snapshot updatePolicy (default daily) hasn't elapsed and the old timestamped build is cached. Run `mvn -U` (or clear the cached snapshot) to force a fresh resolve.
  • If two remote repositories both contain a different copy of the same GAV, which is used?
    The first one in resolution order that returns it; subsequent repos aren't consulted once it's found and cached. Mirrors override the URL entirely.
  • Why might a build still succeed after an artifact is removed from the remote?
    Because a release artifact already cached in ~/.m2 is reused and never re-downloaded.

saying these in an interview costs you the question

  • Saying Maven re-downloads release artifacts on every build.
  • Claiming remote repos are tried in alphabetical or random order rather than declaration order.
  • Treating SNAPSHOT and release artifacts as having identical update behaviour.
  • Forgetting that mirrors can redirect resolution.

context

resolving links…