skip to content

Mirrors & Repository Managers

2 roadmaps5 questions

Mirrors and mirrorOf patterns, repository managers proxying the public internet, and per-repository checksum and update policies. Asked because behind a corporate firewall this is the first thing that has to be configured correctly.

on this pageshow

explore

questions

5

What is a mirror in Maven's settings.xml, and why would a team configure one?

level: juniorimportance: must knowfreq 70%

answer

  1. settings.xml <mirror>
  2. mirrorOf matches repo ids
  3. url substitutes endpoint
  4. / external:* / !negation
  5. credentials use mirror id

basics

~10 s

A mirror in settings.xml redirects requests for one or more repositories to a different URL. Teams use it to point all downloads at an internal repository manager instead of public servers.

solid answer

~40 s

A `<mirror>` entry in `settings.xml` intercepts requests that Maven would normally send to a declared repository (matched by `<mirrorOf>`) and serves them from the mirror's `<url>` instead. The original repository's id is effectively replaced by the mirror at resolution time. Teams configure mirrors to route every dependency download through an internal repository manager (Nexus/Artifactory) for caching, speed, reliability, and policy control, and to avoid hammering public servers like Maven Central. A common pattern is a single mirror with `<mirrorOf>*</mirrorOf>` or `external:*` pointing at the corporate manager. Because the mirror's id replaces the original repo id, server credentials in `<servers>` must reference the mirror's id, not the original repository id.

code

xml · 5 lines
xml
<mirror>
  <id>corp-nexus</id>
  <url>https://nexus.corp.example/repository/maven-public/</url>
  <mirrorOf>external:*</mirrorOf>
</mirror>

go deeper

for a junior

Knows a mirror in settings.xml redirects downloads to an internal server.

for a middle

Knows mirrorOf patterns (, external:, lists) and that the mirror url substitutes the endpoint.

for a senior

Handles the credentials-on-mirror-id gotcha and chooses * vs external:* deliberately.

for a principal

Designs org-wide settings.xml distribution, mirror-of strategy, and fallback/air-gap policy.

## What a repository is first Maven downloads dependencies and plugins from **remote repositories** — HTTP servers holding artifacts in a standard layout (`groupId/artifactId/version/...`). By default Maven knows **Maven Central**. Projects can declare extra repositories in the `pom.xml` `<repositories>` element, each with an `<id>` and `<url>`. ## What a mirror is A **mirror** is a setting in your user-level `~/.m2/settings.xml` (or global `$M2_HOME/conf/settings.xml`) that says: *whenever Maven wants to talk to repository X, talk to my mirror URL instead*. It does not add a new repository; it **substitutes** the endpoint for repositories that already exist. Key sub-elements of a `<mirror>`: - `<id>` — unique id for the mirror; also the key used to match `<server>` credentials. - `<url>` — where requests are actually sent. - `<mirrorOf>` — which repository ids this mirror serves for. ## mirrorOf matching syntax - `central` — mirrors only the repository with id `central`. - `*` — mirrors every repository. - `external:*` — mirrors all repositories **except** those on localhost or using `file://` (i.e. only truly external ones). - `external:http:*` — like above but only plain-HTTP externals. - `repo1,repo2` — comma list of ids. - `*,!internal` — everything except the repo with id `internal` (negation with `!`). The first matching mirror wins; order matters when patterns overlap. ## Why teams use mirrors - **Single chokepoint:** route all traffic through one corporate repository manager for caching and audit. - **Speed/reliability:** a nearby cache is faster and survives upstream outages. - **Governance/security:** block or vet artifacts centrally; avoid leaking which dependencies you use to public servers. - **Air-gapped builds:** the mirror is the only reachable host. ## Credentials gotcha Because the mirror's id replaces the original repository id during resolution, authentication must be configured against the **mirror's** id in `<servers>`, not the original repo id. ```xml <settings> <mirrors> <mirror> <id>corp-nexus</id> <name>Corporate Nexus</name> <url>https://nexus.corp.example/repository/maven-public/</url> <mirrorOf>*</mirrorOf> </mirror> </mirrors> <servers> <server> <id>corp-nexus</id> <username>build</username> <password>${env.NEXUS_TOKEN}</password> </server> </servers> </settings> ```

  • If you mirror a repository, where must its credentials go?
    Under <servers> keyed by the mirror's <id>, because the mirror id replaces the original repository id during resolution.
  • Does a mirror add a new repository to the build?
    No. It only redirects requests for repositories Maven already knows about; if no declared repo matches the mirrorOf pattern, the mirror is never used.

A mirror is like call-forwarding: dial the original number (repo id) and the call is silently routed to a different line (the mirror url).

saying these in an interview costs you the question

  • Saying a mirror adds a new repository (it substitutes an existing one)
  • Putting credentials under the original repo id instead of the mirror id
  • Confusing a mirror with a <repository> in pom.xml

context

resolving links…

open as a page

Explain the mirrorOf matching syntax, including external:* and negation. How do you mirror everything except one internal repo?

level: middleimportance: should knowfreq 55%

basics

~10 s

mirrorOf decides which repository ids a mirror handles. Use * for all, external:* for non-local ones, a comma list of ids, or *,!internal to mirror everything except the repo with id 'internal'.

open as a page

What role does a repository manager like Nexus or Artifactory play, and how does proxying remotes work?

level: middleimportance: should knowfreq 60%

basics

~20 s

A repository manager (Nexus, Artifactory) is a server that hosts your own artifacts and proxies/caches public repos like Maven Central. Builds point at it via a mirror, so dependencies are cached locally and downloaded once.

open as a page

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

level: seniorimportance: should knowfreq 45%

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

open as a page

How would you lock down builds to a single trusted repository and prevent developers from pulling directly from arbitrary remotes?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

Distribute a managed settings.xml with one mirror using mirrorOf=* (or external:*) pointing at the corporate manager, and optionally a <blocked> mirror to reject other remotes. Then no matter what repos a pom declares, everything routes through the trusted server.

open as a page