Maven profiles let you define alternate build configurations — different dependencies, properties, or plugin settings — that can be activated selectively for different environments like dev, test, or production, without maintaining separate pom.xml files. Only the active profile's settings are merged into the effective build.
Key Points: • Profiles are declared in a <profiles> section of pom.xml, each with its own <id> and configuration overrides. • Activation can be manual, via the command line with -P profile-id, or automatic, based on conditions like a system property, JDK version, or OS. • Profiles can override properties, dependencies, plugin configuration, or even the build's resource directories. • This keeps environment-specific values (like a database URL) out of the main configuration and lets CI select the right profile for each deployment target. • Overuse of profiles can make builds harder to reason about, so it's best to keep profile-specific differences minimal and well-documented.
Example: A project might define a "prod" profile that swaps in a production-optimized logging configuration and a "dev" profile with verbose debug logging, activated respectively via mvn package -Pprod or mvn package -Pdev.
Code Example:
<profiles>
<profile>
<id>prod</id>
<properties>
<log.level>WARN</log.level>
</properties>
</profile>
<profile>
<id>dev</id>
<properties>
<log.level>DEBUG</log.level>
</properties>
</profile>
</profiles>Interview Tip: A concise interview answer is:
"Maven profiles let me define environment-specific overrides for properties, dependencies, or plugin config in one pom.xml, activated either manually with -P or automatically based on conditions like OS or a system property. This keeps a single project configuration flexible across dev, test, and prod without duplicating the whole build file."