skip to content

Repositories, Release & Publishing

2 roadmaps29 questions

Where artifacts come from and where releases go: the local cache, remote repositories and mirrors, snapshot versus release rules, deployment, signing, and Maven Central. Interviewers ask because publishing is the part most developers never touch until they must.

on this pageshow

explore

questions

29

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

What is the difference between a SNAPSHOT version and a release version in Maven, and why does it matter for a release process?

level: juniorimportance: must knowfreq 75%

basics

~10 s

A SNAPSHOT (e.g. 1.0.0-SNAPSHOT) is a mutable in-development version that can change at any time; a release (e.g. 1.0.0) is immutable and published once. Releasing means dropping -SNAPSHOT and locking the artifact.

open as a page

What is the Maven local repository, where does it live, and what is it used for?

level: juniorimportance: must knowfreq 75%

basics

~10 s

The local repository is a folder on your machine (by default ~/.m2/repository) where Maven caches every downloaded dependency and plugin, plus artifacts you build and install yourself, so it doesn't re-download them.

open as a page

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%

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.

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 sign release artifacts for Maven Central, and how is signing typically wired into the build?

level: middleimportance: must knowfreq 48%

basics

~20 s

Use the maven-gpg-plugin. It runs in the verify phase, creates a detached .asc signature for each artifact (jar, sources, javadoc, pom) using your GPG key, and your public key must be on a public keyserver so Sonatype can verify it.

open as a page

What POM metadata is required for a Maven Central release, and why?

level: middleimportance: must knowfreq 50%

basics

~10 s

You need name, description, url, at least one license, an scm block (source control URLs), and at least one developer. These let consumers identify, license-check, and trace the artifact.

open as a page

Walk me through what maven-release-plugin's release:prepare and release:perform actually do.

level: middleimportance: must knowfreq 65%

basics

~10 s

release:prepare strips -SNAPSHOT, commits, tags in SCM, then bumps to the next -SNAPSHOT and commits again. release:perform checks out that tag into a clean dir and runs deploy to publish the release artifacts.

open as a page

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

level: middleimportance: must knowfreq 60%

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.

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

What is Maven Central, and at a high level what does it take to publish an artifact there?

level: juniorimportance: should knowfreq 45%

basics

~10 s

Maven Central is the default public repository where Maven downloads dependencies. To publish, you need a registered namespace (groupId), full POM metadata, GPG-signed artifacts, and you upload through Sonatype's Central Portal.

open as a page

What is Maven Central, and how does Maven know to use it by default?

level: juniorimportance: should knowfreq 55%

basics

~20 s

Maven Central is the big public default remote repository of open-source artifacts. Maven knows about it because it's defined in the built-in Super POM that every project inherits, so you don't have to configure anything.

open as a page

Can you publish SNAPSHOT versions to Maven Central? Explain SNAPSHOT vs release semantics in this context.

level: middleimportance: should knowfreq 40%

basics

~10 s

No. Maven Central only accepts final release versions. SNAPSHOTs are mutable in-development versions and go to a separate snapshot repository, not Central. Released versions are immutable.

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 you use the versions-maven-plugin to manage dependency and project versions, and what does versions:set vs versions:use-latest-versions do?

level: middleimportance: should knowfreq 50%

basics

~10 s

versions-maven-plugin edits POM versions for you. versions:set changes the project's own version (across a multi-module build); versions:use-latest-versions bumps your declared dependencies to their newest available versions. It writes pom.xml.versionsBackup so you can revert.

open as a page

When and how would you use Maven's offline mode, and what are its prerequisites and pitfalls?

level: middleimportance: should knowfreq 35%

basics

~20 s

Offline mode (mvn -o or --offline) tells Maven not to contact any remote repository and to build using only what's already in the local ~/.m2 cache. It's useful with no internet, but fails if anything needed isn't cached yet.

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

Contrast the Central Portal (central-publishing-maven-plugin) with the legacy OSSRH/Nexus staging flow. How does a deploy-to-release work in each?

level: seniorimportance: should knowfreq 35%

basics

~20 s

Legacy OSSRH used a Nexus staging repository: you deploy, a staging repo is created, you close it (runs validations), then release it. The new Central Portal uses central-publishing-maven-plugin to upload a deployment bundle that's validated and published; OSSRH is being retired.

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

Explain Maven's CI-friendly versions using ${revision}, ${sha1}, and ${changelist}. Why are they used and what pitfall do they introduce?

level: seniorimportance: should knowfreq 45%

basics

~20 s

CI-friendly versions put a single version in one property (${revision}, plus optional ${sha1}/${changelist}) so you set it once, e.g. via -Drevision=1.2.3, instead of editing every module. The pitfall: the published POM still contains the literal ${revision}, so you must use flatten-maven-plugin to resolve it.

open as a page

How do you add a non-Central remote repository, and where should that configuration live for a team?

level: seniorimportance: should knowfreq 45%

basics

~20 s

You can add a remote with a <repository> block in the pom.xml, but for a team it's better to define it (and credentials) in settings.xml or, best of all, route everything through one internal repository manager so the pom stays clean and portable.

open as a page

What is maven-metadata.xml and what role does it play, especially for SNAPSHOT artifacts?

level: seniorimportance: should knowfreq 40%

basics

~20 s

maven-metadata.xml is a small index file in a repository that lists the available versions of an artifact (and, for snapshots, the latest timestamped build). Maven reads it to figure out which concrete version to download.

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

What does flatten-maven-plugin do, and beyond CI-friendly versions, when else is a flattened POM valuable?

level: seniorimportance: nice to knowfreq 30%

basics

~10 s

flatten-maven-plugin generates a resolved, self-contained POM (.flattened-pom.xml) that is installed/deployed instead of the original. It inlines the parent, resolves properties like ${revision}, and can strip build-only sections so consumers get a clean, fully-resolved POM.

open as a page

Design a reliable, automated CI pipeline that publishes a library to Maven Central on a tagged release. What are the moving parts and failure modes?

level: principalimportance: nice to knowfreq 22%

basics

~20 s

On a version tag, CI builds signed artifacts (jar/sources/javadoc/pom + GPG .asc) with full metadata, then uses central-publishing-maven-plugin to upload and auto-publish. Secrets (GPG key, passphrase, Central token) come from the CI secret store, not the repo.

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

Your team is moving releases into CI/CD. Would you keep maven-release-plugin or adopt CI-friendly versions with flatten + versions plugin? How do you decide?

level: principalimportance: nice to knowfreq 25%

basics

~20 s

It depends on who owns versioning and tagging. maven-release-plugin is SCM-driven and makes commits/tags itself; CI-friendly versions let the pipeline stamp the version (-Drevision) with flatten resolving the POM and the pipeline owning the git tag. For modern GitOps CI, the CI-friendly approach is usually cleaner.

open as a page