skip to content

What is the difference between declaring a profile in pom.xml versus settings.xml, and when do you choose each?

level: seniorimportance: should knowfreq 55%

answer

  1. pom = committed, full power
  2. settings = local, properties+repos only
  3. no deps/plugins in settings profile
  4. <activeProfiles> in settings
  5. secrets/mirrors -> settings.xml

basics

~20 s

pom.xml profiles travel with the project and can change almost anything in the build. settings.xml profiles live on the developer's machine (~/.m2), aren't committed, and are limited to properties, repositories, and plugin repositories — good for machine-specific or secret values.

solid answer

~40 s

A profile in `pom.xml` is version-controlled with the project, shared by everyone, and can override the full range of build configuration — `dependencies`, `build`/`plugins`, `properties`, `repositories`, `modules`, `reporting`. A profile in `settings.xml` (user `~/.m2/settings.xml` or the global install settings) is per-machine, NOT committed, and is intentionally **restricted**: it may only set `<properties>`, `<repositories>`, `<pluginRepositories>`, and be activated/listed via `<activeProfiles>` — it cannot add dependencies or configure plugins. So: put environment-agnostic, shareable build variation (release flags, module sets, plugin executions) in the POM; put machine- or user-specific and secret things (mirror URLs, credentials-bearing repo definitions, local paths) in settings.xml so they stay off version control. `<activeProfiles>` in settings.xml force-activates listed ids globally.

code

xml · 12 lines
xml
<!-- ~/.m2/settings.xml -->
<settings>
  <profiles>
    <profile>
      <id>corp-repo</id>
      <repositories>
        <repository><id>nexus</id><url>https://nexus.corp/repo</url></repository>
      </repositories>
    </profile>
  </profiles>
  <activeProfiles><activeProfile>corp-repo</activeProfile></activeProfiles>
</settings>

go deeper

for a junior

Know pom.xml profiles are committed and settings.xml profiles are local/per-machine.

for a middle

Know settings.xml profiles are limited to properties and repository definitions.

for a senior

Decide placement by reproducibility vs secrecy; keep credentials out of the committed POM.

for a principal

Define org policy: shared build behavior in POM, machine/secret config in distributed settings.xml templates, never secrets in VCS.

## Two homes for profiles Profiles can be declared in two places, and the choice has real consequences. ### pom.xml profiles - **Committed** with the project; everyone who builds gets them. - **Full power**: can override or add `<dependencies>`, `<dependencyManagement>`, `<build>` (plugins, plugin configuration, executions, finalName), `<properties>`, `<repositories>`, `<pluginRepositories>`, `<modules>`, and `<reporting>`. - Right place for build variation that is part of the project's contract: a `release` profile that runs GPG signing, a `docker` profile that adds a packaging plugin, a profile that includes extra modules. ### settings.xml profiles - Live in `~/.m2/settings.xml` (user) or `$MAVEN_HOME/conf/settings.xml` (global). **Not** in the project, **not** committed. - **Deliberately limited**: a settings.xml profile may only declare `<properties>`, `<repositories>`, and `<pluginRepositories>`. It cannot add dependencies or configure plugins (those would be invisible to teammates and break reproducibility). - Right place for machine/user/secret config: an internal mirror, a corporate repository definition with credentials referenced from `<servers>`, or a developer's local property. ### Activating settings profiles ```xml <settings> <profiles> <profile> <id>corp-repo</id> <repositories> <repository> <id>nexus</id> <url>https://nexus.corp/repo</url> </repository> </repositories> </profile> </profiles> <activeProfiles> <activeProfile>corp-repo</activeProfile> </activeProfiles> </settings> ``` `<activeProfiles>` force-activates the listed ids for every build on that machine. ## Choosing | Need | Where | |------|-------| | Release/signing/packaging variation shared by team | pom.xml | | Extra modules or dependencies per condition | pom.xml | | Internal mirror / repo with credentials | settings.xml | | Per-developer local path or toggle | settings.xml | | Anything secret or machine-specific | settings.xml | ## Rule of thumb If a teammate or CI must reproduce it, it belongs in the POM. If it's secret or unique to one machine, it belongs in settings.xml.

  • Can a settings.xml profile add a dependency to your build?
    No. settings.xml profiles are restricted to properties, repositories, and pluginRepositories. Adding dependencies/plugins is only allowed in pom.xml profiles to keep builds reproducible across machines.
  • How do you force-activate a settings.xml profile for every build on a machine?
    List its id under `<activeProfiles><activeProfile>...</activeProfile></activeProfiles>` in settings.xml.

saying these in an interview costs you the question

  • Putting credentials or secrets in a committed pom.xml profile.
  • Trying to add dependencies or plugin config in a settings.xml profile (not supported).
  • Claiming both files have identical profile capabilities.

context

resolving links…