Maven Profiles for Environment-Specific Builds
Fast recall
Quick revision
Core answer
pom.xml or settings.xml, activate them with -P profile-id on the command line or via automatic activation conditions (OS, property, file presence).Whether you understand how to vary build behavior across environments without maintaining multiple POMs.
Putting sensitive credentials directly in `pom.xml` profiles instead of in `~/.m2/settings.xml` (which is not committed to version control).
Mention automatic activation by property (`-Dproperty=value`), OS, or JDK version; the `<activeByDefault>` flag and its pitfall (it deactivates when any other profile is activated); and using Spring Boot profiles alongside Maven profiles.
Interview-ready guide
Interview answer
Maven profiles let you activate different POM sections based on flags, environment variables, or conditions — the standard mechanism for varying build behavior between developer machines and CI without separate POMs.
Profile activation
- Explicit activation:
-Preleaseon the command line activates thereleaseprofile; multiple profiles can be active simultaneously with-Pprofile1,profile2 - Property-based activation: a profile that activates when
env.CIis set works identically across GitHub Actions, Jenkins, and GitLab without any pipeline-specific configuration — the CI environment sets the variable automatically - The
activeByDefaulttrap: a profile withtrue -Preleasesilently disables what they thought was always-on
What profiles are good for
- Skipping integration tests locally while running them in CI: the CI profile sets
maven.failsafe.skip=falseand enables JaCoCo; the default profile skips both for developer speed - Switching Spring active profiles: a CI profile sets
spring.profiles.active=testvia Surefire system properties - Enabling GPG signing only in the
releaseprofile — signing on every local build is unnecessary overhead
The credential security rule
- Never put credentials in
pom.xmlprofiles — Nexus passwords, signing keys, and API tokens belong in~/.m2/settings.xml, which lives outside the project directory and is never committed - In CI, generate
settings.xmlfrom pipeline secrets using a build step before Maven runs — the URL stays in the POM, the credential stays in the pipeline secret store - Teams that commit Nexus passwords to pom.xml profiles routinely expose them in public repositories or leak them through repository forks
Maven Profiles for Environment-Specific Builds
Direct Answer
Maven profiles are POM sections that activate conditionally to modify build configuration. You define them with <profiles><profile> blocks in pom.xml or settings.xml, activate them with -P profile-id on the command line or via automatic activation conditions (OS, property, file presence).
Common Mistakes & Pitfalls
Putting sensitive credentials directly in pom.xml profiles instead of in ~/.m2/settings.xml (which is not committed to version control).
Check your understanding
Answer these without looking back at the article.
- How do Maven profiles interact with Spring Boot's application profiles?
- How do you activate a Maven profile based on an environment variable in CI?
- What is the difference between profiles defined in `pom.xml` versus `settings.xml`?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.