skip to content

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

level: seniorimportance: should knowfreq 45%

answer

  1. <repository> deps vs <pluginRepository> plugins
  2. settings.xml for team + creds
  3. <server> id matches repo id
  4. mirror -> one Nexus/Artifactory
  5. never creds in POM

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.

solid answer

~40 s

Technically you add a remote by declaring a `<repository>` (for dependencies) and/or `<pluginRepository>` (for plugins) with an id, url, and `<releases>`/`<snapshots>` policies in the POM. But hardcoding extra repositories in the POM is generally discouraged: it couples the project to specific infrastructure, can't carry credentials safely, and means each consumer also hits those repos. The team-scale pattern is a single **repository manager** (Nexus/Artifactory) that proxies Central plus any third-party and internal repos, configured via a `<mirror>` with `<mirrorOf>*</mirrorOf>` in `settings.xml`. Credentials go in `<servers>` (id matching the repo/mirror id), never in the POM. This keeps POMs portable, centralizes policy (CVE/license gating, caching, availability), and avoids leaking secrets. When you must declare a repo in the POM (e.g. an OSS library that lives off Central), pair it with sensible snapshot/release policies.

code

xml · 16 lines
xml
<settings>
  <mirrors>
    <mirror>
      <id>nexus</id>
      <mirrorOf>*</mirrorOf>
      <url>https://nexus.example.com/repository/maven-public/</url>
    </mirror>
  </mirrors>
  <servers>
    <server>
      <id>nexus</id>
      <username>ci</username>
      <password>${env.NEXUS_TOKEN}</password>
    </server>
  </servers>
</settings>

go deeper

for a junior

Know a remote can be added with a <repository> block in the POM.

for a middle

Distinguish repositories vs pluginRepositories and put credentials in settings.xml servers.

for a senior

Argue for settings.xml + a repository manager mirror over POM repos; manage secrets safely.

for a principal

Set org policy: single proxying repository manager, supply-chain gating, credential management, portable POMs.

## Two places you can add a remote ### 1. In the POM (`<repositories>`) ```xml <repositories> <repository> <id>jitpack</id> <url>https://jitpack.io</url> <releases><enabled>true</enabled></releases> <snapshots><enabled>false</enabled></snapshots> </repository> </repositories> <pluginRepositories> <pluginRepository> <id>internal-plugins</id> <url>https://nexus.example.com/repository/plugins/</url> </pluginRepository> </pluginRepositories> ``` Note: `<repositories>` is for **dependencies**; plugins need `<pluginRepositories>` separately. Each can independently enable/disable `releases` and `snapshots` and set an `updatePolicy`. ### 2. In settings.xml (per-user / per-agent) For team use, configuration lives in `~/.m2/settings.xml`, typically via a **mirror** that redirects everything to one repository manager: ```xml <settings> <mirrors> <mirror> <id>nexus</id> <mirrorOf>*</mirrorOf> <url>https://nexus.example.com/repository/maven-public/</url> </mirror> </mirrors> <servers> <server> <id>nexus</id> <username>ci</username> <password>${env.NEXUS_TOKEN}</password> </server> </servers> </settings> ``` The `<server>` id must match the repository/mirror id so credentials attach to it. Secrets should come from environment variables or an encrypted password store, not be committed. ## Why prefer settings.xml + a repository manager - **Portable POMs**: the project builds anywhere; infra details aren't baked in. - **No secrets in source**: credentials live in settings.xml/servers, outside the repo. - **Central policy**: one place to cache, proxy Central, gate licenses/CVEs, and stay resilient to upstream outages. - **Consistency**: every developer and CI agent resolves from the same controlled source. ## When POM-level repos are acceptable For a published OSS library that genuinely depends on an artifact only available from a specific public repo, declaring it in the POM is reasonable — but be conservative with snapshot enablement, because consumers inherit it. ## Pitfalls - Putting credentials in the POM (they'd be published). - Forgetting `<pluginRepositories>` and being puzzled why a plugin won't resolve. - Declaring many POM repos, which slows resolution (each miss may probe several servers) and harms reproducibility.

  • Where do repository credentials belong and how are they linked to a repo?
    In settings.xml `<servers>`, with the `<server><id>` matching the repository or mirror id. Never in the POM, and ideally sourced from env vars or an encrypted store.
  • Why declare `<pluginRepositories>` separately from `<repositories>`?
    Maven resolves plugins from plugin repositories and dependencies from regular repositories; a custom plugin source must be listed under pluginRepositories or the plugin won't be found.
  • What's the downside of listing many remote repositories in the POM?
    Each cache miss may probe several servers (slower, flakier), credentials can't be stored safely, and it couples the build to specific infra, hurting portability and reproducibility.

saying these in an interview costs you the question

  • Putting usernames/passwords in pom.xml.
  • Assuming `<repositories>` also covers plugins.
  • Recommending many POM-level repos instead of one mirrored repository manager for a team.

context

resolving links…