skip to content

What is the 'effective POM' in Maven, and how does it differ from the pom.xml you write by hand?

level: juniorimportance: must knowfreq 70%

answer

  1. computed final model
  2. Super POM defaults
  3. merge parents + profiles
  4. help:effective-pom
  5. explicit vs authored

basics

~10 s

The effective POM is the final, fully-merged project model Maven actually builds with. It combines your pom.xml with the built-in Super POM, parent POMs, and active profiles, filling in all defaults.

solid answer

~40 s

The effective POM is the complete, computed project model Maven uses at build time. Your hand-written pom.xml is usually small; Maven merges it on top of the built-in Super POM (which supplies default repositories, build directories like target/, and core plugin bindings), then layers any parent POMs, dependency/plugin management, settings, and active profiles. The result is a fully-resolved model with every default and inherited value made explicit. You inspect it with `mvn help:effective-pom`. This matters for debugging: when you wonder 'where did this repository / plugin version / source directory come from?', the effective POM shows the resolved truth rather than the sparse file you authored.

code

bash · 2 lines
bash
mvn help:effective-pom
mvn help:effective-pom -Doutput=effective-pom.xml

go deeper

for a junior

Knows the effective POM is the merged final model and that help:effective-pom prints it.

for a middle

Can list the merge layers (Super POM, parents, project, profiles) and what each contributes.

for a senior

Uses the effective POM to debug surprising plugin versions, repositories, or properties and explains precedence.

for a principal

Designs parent/BOM hierarchies knowing how the effective model resolves, and teaches teams to reason from it.

## What the effective POM is When you write a `pom.xml`, you only specify what differs from defaults. Maven does NOT build from that sparse file directly. Instead it computes an **effective POM**: the complete project model after merging several layers, with every default and inherited value resolved to a concrete value. ## The layers that get merged (lowest to highest precedence) 1. **Super POM** — a POM built into Maven itself (it is the implicit parent of every project). It supplies sensible defaults: the Central repository, default directories (`src/main/java`, `target/`, `target/classes`), default resource locations, and bindings for core plugins. You never see it as a file; it ships inside `maven-model-builder`. 2. **Parent POM(s)** — if your project declares a `<parent>`, its values are inherited, and parents can themselves have parents, forming an inheritance chain rooted at the Super POM. 3. **Your project's pom.xml** — your explicit declarations override inherited ones. 4. **Active profiles** — profiles (from the POM, `settings.xml`, or `~/.m2/settings.xml`) that are active inject/override values into the computed model. ## The required header Every POM starts with `<modelVersion>4.0.0</modelVersion>`, which tells Maven 3/4 which POM schema to use. It is mandatory. ## How to see it ```bash mvn help:effective-pom mvn help:effective-pom -Doutput=effective-pom.xml ``` This prints the fully-resolved XML — far longer than your file — showing inherited plugins, default repositories, and resolved properties. ## Why it matters The effective POM is the single source of truth for 'what will Maven actually do'. If a plugin runs with a surprising version, a repository you never added is queried, or a property has an unexpected value, the effective POM reveals exactly where it came from.

  • Where does the Super POM physically live?
    It is bundled inside Maven (in the maven-model-builder jar), not in your project; it is the implicit parent of every POM.
  • Name one thing the Super POM provides by default.
    Maven Central as a default repository (in Maven 3), default directory layout (src/main/java, target/), and default lifecycle plugin bindings.

Your pom.xml is a diff; the effective POM is the whole file after the diff is applied on top of all the defaults.

saying these in an interview costs you the question

  • Saying Maven builds directly from the literal pom.xml without merging defaults.
  • Thinking the Super POM is a file in your project you can edit.
  • Confusing effective POM with effective settings (help:effective-settings).

context

resolving links…