skip to content

How do profiles in settings.xml work, including activeProfiles and activation, and how do they differ from POM profiles?

level: seniorimportance: should knowfreq 40%

answer

  1. settings profiles: repos/pluginRepos/properties only
  2. no dependencies/plugins/build changes in settings profiles
  3. <activeProfiles> always-on; <activation> conditional; -P CLI
  4. activation: jdk/os/property/file
  5. POM profiles = full build power; help:active-profiles

basics

~20 s

settings.xml can define <profiles> for machine-specific config (repos, properties) and turn them on with <activeProfiles> or activation rules. Unlike POM profiles, settings profiles can't change build steps (plugins/dependencies) — only repositories, plugin repositories, and properties.

solid answer

~40 s

Profiles in `settings.xml` let a machine carry environment-specific configuration. They are declared under `<profiles>` and activated either explicitly via `<activeProfiles>` (always on), by `<activation>` rules (JDK version, OS, a property, a file's presence/absence), or on the command line with `-P`. A key limitation: **settings.xml profiles are restricted** — they can only set `<repositories>`, `<pluginRepositories>`, and `<properties>`. They **cannot** add dependencies, plugins, or change the build, because that would make builds non-portable (the POM wouldn't be self-contained). POM profiles, by contrast, are full build profiles that can alter plugins, dependencies, and lifecycle. So put portable build variation in POM profiles and machine/credentials-flavored repo+property variation in settings profiles. Use `mvn help:active-profiles` to see what's active and why.

code

xml · 15 lines
xml
<profiles>
  <profile>
    <id>company-repos</id>
    <repositories>
      <repository>
        <id>internal</id>
        <url>https://nexus.example.com/repository/maven-public/</url>
      </repository>
    </repositories>
    <properties><env>corp</env></properties>
  </profile>
</profiles>
<activeProfiles>
  <activeProfile>company-repos</activeProfile>
</activeProfiles>

go deeper

for a junior

Knows profiles exist and can be turned on with activeProfiles or -P.

for a middle

Knows activation triggers (jdk/os/property/file) and that settings profiles set repos/properties.

for a senior

Articulates the settings-vs-POM profile restriction and chooses the right place for variation.

for a principal

Sets org conventions so machine config stays in settings profiles and portable build variation stays in the POM.

## Profiles, briefly A **profile** is a named bundle of configuration that can be toggled on or off, letting one project behave differently per environment (dev/CI/prod) or per machine. Maven has profiles in two places — the **POM** and **settings.xml** — with different powers. ## settings.xml profiles Declared under `<profiles>` in settings.xml, they are deliberately **limited** to: - `<repositories>` and `<pluginRepositories>` — extra artifact/plugin sources. - `<properties>` — values usable in the build. They **cannot** declare dependencies, plugins, or build steps. The reason is portability: settings.xml is not shared with the project, so allowing it to change the build would make the same POM produce different artifacts on different machines. ## Activating profiles 1. **`<activeProfiles>`** — list profile ids that are always active: ```xml <activeProfiles> <activeProfile>company-repos</activeProfile> </activeProfiles> ``` 2. **`<activation>`** inside a profile — conditional auto-activation: ```xml <profile> <id>jdk21</id> <activation> <jdk>21</jdk> <!-- or <os>, <property>, <file> existence --> </activation> <properties><target.java>21</target.java></properties> </profile> ``` 3. **Command line** `-P company-repos` and `-P !company-repos` to force on/off. Activation triggers include JDK version (`<jdk>`), OS family/arch (`<os>`), presence/value of a system property (`<property>`), and existence/absence of a file (`<file><exists>`/`<missing>`). ## Inspecting ```bash mvn help:active-profiles # which profiles are active and from where mvn help:effective-settings # merged settings incl. profiles ``` ## settings vs POM profiles — when to use which - **POM profiles**: portable build variation — different plugin config, dependency sets, lifecycle for dev vs release. Travels with the project. - **settings profiles**: machine-local repo lists and properties (e.g. an internal repo URL, a username property). Stays off version control. Putting build-affecting variation in settings profiles is an anti-pattern because it breaks reproducibility for anyone without your settings.xml.

  • Can a settings.xml profile add a dependency or plugin?
    No. settings.xml profiles are restricted to <repositories>, <pluginRepositories>, and <properties>; only POM profiles can change dependencies/plugins/build to keep builds portable.
  • What are the ways to activate a settings profile?
    List it in <activeProfiles> (always on), use an <activation> rule (jdk/os/property/file), or pass -P on the command line (and -P! to deactivate).

saying these in an interview costs you the question

  • Claiming you can add dependencies/plugins via a settings.xml profile.
  • Confusing <activeProfiles> (always on) with <activation> (conditional).
  • Putting environment build logic in settings profiles, breaking reproducibility for others.

context

resolving links…