skip to content

Repository Model

2 roadmaps6 questions

The ~/.m2 cache, remote repository declarations, maven-metadata.xml, resolution order, and offline mode. Interviewers want to hear what really happens on a cache miss, and whether deleting ~/.m2 counts as a fix.

on this pageshow

explore

questions

6

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

level: juniorimportance: must knowfreq 75%

answer

  1. ~/.m2/repository
  2. GAV -> path layout
  3. cache + install target
  4. mutable, can corrupt
  5. enables offline

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.

solid answer

~40 s

The local repository is Maven's on-disk cache, by default at `~/.m2/repository` (overridable via `<localRepository>` in `settings.xml` or `-Dmaven.repo.local`). When a build needs a dependency or plugin, Maven first checks here; on a miss it downloads from a remote repository and stores it locally for reuse. It also holds artifacts you produce with `mvn install`, making them available to other local projects. Each artifact sits under a path derived from its GAV coordinates: `groupId` (dots become slashes) / `artifactId` / `version` / `artifactId-version.jar` (plus `.pom`, `.sha1`, etc.). Because it is a shared mutable cache, a corrupted or partial download there can poison later builds; deleting the offending directory forces a re-fetch. This caching is what makes incremental local builds fast and enables offline mode.

code

bash · 3 lines
bash
mvn help:evaluate -Dexpression=settings.localRepository -q -DforceStdout
# default: /Users/you/.m2/repository
mvn -Dmaven.repo.local=$PWD/.m2-ci clean verify

go deeper

for a junior

Know it is ~/.m2/repository and acts as a download cache.

for a middle

Explain GAV->path layout, checksum files, and how install populates it.

for a senior

Discuss cache corruption, isolating maven.repo.local in CI for reproducibility.

for a principal

Govern shared-cache hygiene, ephemeral CI repos, and why a per-user mutable cache undermines reproducibility guarantees.

## What it is Maven needs JAR files (libraries) and plugins to build a project. Instead of fetching them from the internet every time, it keeps a **local repository** — a directory tree on your own machine that acts as a cache. ## Where it lives By default it is `~/.m2/repository` (on Windows, `%USERPROFILE%\.m2\repository`). You can move it: - Set `<localRepository>` in `~/.m2/settings.xml`. - Pass `-Dmaven.repo.local=/some/path` on the command line (useful for isolated CI builds). ## How artifacts are stored (the layout) Every artifact is identified by **GAV coordinates**: `groupId`, `artifactId`, `version`. Maven turns those into a path: - `groupId` dots become directory separators. - Then `artifactId`, then `version`, then the file. So `org.apache.commons:commons-lang3:3.14.0` lands at `org/apache/commons/commons-lang3/3.14.0/commons-lang3-3.14.0.jar`, alongside `commons-lang3-3.14.0.pom` and checksum files (`.sha1`, `.md5`). ## What goes into it - Dependencies downloaded from remote repositories. - Plugins Maven downloads to run goals. - Artifacts **you** build and run `mvn install` on (so sibling projects on the same machine can depend on them). ## Why it matters - Speed: second and later builds reuse cached files. - Offline builds: once populated, `mvn -o` works without a network. - Sharing locally: `install` publishes to the local repo only — not to a team server (that's `deploy`). ## Gotchas - It is a **mutable shared cache**. A truncated download can leave a broken JAR that future builds keep using; deleting that artifact's folder forces a clean re-download. - It is per-user, so two developers can have subtly different caches — never treat "works on my machine" as proof when caches diverge. ```bash # See where Maven thinks the local repo is mvn help:evaluate -Dexpression=settings.localRepository -q -DforceStdout # Use an isolated local repo (great for reproducible CI) mvn -Dmaven.repo.local=$PWD/.m2-ci clean verify ```

  • How is the on-disk path for an artifact derived?
    From its GAV: groupId with dots replaced by slashes, then artifactId, then version, then artifactId-version.<packaging>, plus .pom and checksum files.
  • What does `mvn install` do versus `mvn deploy`?
    `install` copies the built artifact into your LOCAL repository only; `deploy` uploads it to a configured remote repository for the whole team.

Like a browser cache for JARs: first visit downloads, later visits read from disk.

saying these in an interview costs you the question

  • Saying `mvn install` publishes to Maven Central or a team server (that's deploy).
  • Thinking the local repo is per-project rather than per-user.
  • Believing a corrupted cached JAR auto-heals without deleting it.

context

resolving links…

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

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

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

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