skip to content

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

level: middleimportance: should knowfreq 60%

answer

  1. proxy / hosted / group repos
  2. cache on first request
  3. mirror -> group url for resolve
  4. distributionManagement -> hosted for deploy
  5. central governance & scanning

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.

solid answer

~40 s

A repository manager is a dedicated server (Nexus Repository, JFrog Artifactory) that sits between your builds and the outside world. It offers three repo types: **proxy** (caches a remote like Maven Central on first request), **hosted** (stores your own releases/snapshots), and **group/virtual** (aggregates several proxies and hosted repos behind one URL). Builds set a single Maven mirror pointing at the group URL, so all resolution flows through the manager: it serves cached artifacts, fetches-and-caches on a miss, and serves your internally deployed artifacts. Benefits include faster, deduplicated downloads, resilience to upstream outages, central security/licence scanning, access control, and a `deploy` target via `distributionManagement`. The manager also enforces retention and can block vulnerable or unapproved artifacts before they reach developers.

code

xml · 10 lines
xml
<distributionManagement>
  <repository>
    <id>corp-nexus</id>
    <url>https://nexus.corp.example/repository/maven-releases/</url>
  </repository>
  <snapshotRepository>
    <id>corp-nexus</id>
    <url>https://nexus.corp.example/repository/maven-snapshots/</url>
  </snapshotRepository>
</distributionManagement>

go deeper

for a junior

Knows Nexus/Artifactory cache dependencies so they download once.

for a middle

Distinguishes proxy/hosted/group and wires mirror + distributionManagement.

for a senior

Designs group ordering, deploy targets, and credential separation; reasons about cache resilience.

for a principal

Owns the org topology: security scanning, retention, multi-region caches, and access governance.

## The problem it solves Without a manager, every developer and CI agent downloads dependencies straight from public servers — slow, bandwidth-heavy, fragile when upstream is down, and impossible to govern. A **repository manager** centralizes this. ## Repository types inside a manager - **Proxy (remote) repository:** a local stand-in for an external repo such as Maven Central. On the first request for an artifact it downloads from upstream, **caches** it, and serves the cache thereafter. Subsequent builds never hit the internet for that artifact. - **Hosted repository:** stores artifacts **you** publish — typically split into a *releases* hosted repo and a *snapshots* hosted repo. - **Group / virtual repository:** a single URL that aggregates multiple proxies and hosted repos in a defined order. This is what builds usually target so one URL covers everything. ## How proxying/caching works 1. Build asks the manager (via the Maven mirror) for `com.example:lib:1.2`. 2. Manager checks its group members in order. 3. If a hosted repo has it, it is served. Otherwise a proxy member fetches it from upstream (e.g. Central), stores it, and returns it. 4. The artifact is now cached for everyone. ## Wiring Maven to it Two halves: - **Resolution (download):** a mirror in `settings.xml` (often `mirrorOf=*` or `external:*`) pointing at the **group** URL. - **Deployment (upload):** `distributionManagement` in the pom pointing at the **hosted** release and snapshot repos. ```xml <distributionManagement> <repository> <id>corp-nexus</id> <url>https://nexus.corp.example/repository/maven-releases/</url> </repository> <snapshotRepository> <id>corp-nexus</id> <url>https://nexus.corp.example/repository/maven-snapshots/</url> </snapshotRepository> </distributionManagement> ``` The `<id>`s must match a `<server>` in settings.xml holding deploy credentials. ## Extra value - **Security/licence scanning** (e.g. Nexus Firewall / Xray) quarantines vulnerable artifacts. - **Access control & audit** of who pulls/pushes what. - **Retention/cleanup** policies for old snapshots. - **Offline resilience:** cached artifacts survive upstream outages. ## Mirror vs manager — don't conflate The *mirror* is the Maven-side redirect; the *repository manager* is the server it redirects to. You need both: the manager does the caching/hosting, the mirror tells Maven to use it.

  • What is a 'group' repository for?
    It aggregates multiple proxy and hosted repos behind one URL so builds need only a single mirror/repository entry.
  • How is publishing wired versus resolving?
    Resolving uses a mirror to the group URL; publishing uses distributionManagement pointing at the hosted release/snapshot repos, with credentials in settings.xml <servers>.

Like a company library that borrows books from the national library on demand (proxy), keeps its own publications (hosted), and gives staff one catalog to search (group).

saying these in an interview costs you the question

  • Saying the manager and the mirror are the same thing
  • Forgetting hosted repos for your own artifacts
  • Pointing deploy at the proxy/group instead of the hosted repo

context

resolving links…