skip to content

What does flatten-maven-plugin do, and beyond CI-friendly versions, when else is a flattened POM valuable?

level: seniorimportance: nice to knowfreq 30%

answer

  1. generates .flattened-pom.xml
  2. installed/deployed instead of original
  3. inlines parent + resolves properties
  4. modes: resolveCiFriendliesOnly / oss / bom
  5. add clean execution

basics

~10 s

flatten-maven-plugin generates a resolved, self-contained POM (.flattened-pom.xml) that is installed/deployed instead of the original. It inlines the parent, resolves properties like ${revision}, and can strip build-only sections so consumers get a clean, fully-resolved POM.

solid answer

~40 s

flatten-maven-plugin produces a `.flattened-pom.xml` at build time and configures install/deploy to publish that file instead of your authored `pom.xml`. Depending on `flattenMode`, it resolves CI-friendly version placeholders, inlines the parent POM (so consumers don't need your parent on the repo), resolves `${properties}`, and prunes build-time-only elements (build, profiles, reporting, distributionManagement) that consumers don't need. Common modes: `resolveCiFriendliesOnly` (just fix `${revision}` etc., keep everything else), `oss` (strict, suitable for Maven Central), and `bom` (for dependency BOMs). It is the standard companion to CI-friendly versions, and is also used by library authors to ship a lean, dependency-resolution-only POM and to decouple published artifacts from an internal parent. Add a `clean` execution so the generated file is removed.

code

xml · 10 lines
xml
<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>flatten-maven-plugin</artifactId>
  <version>1.6.0</version>
  <configuration><flattenMode>oss</flattenMode></configuration>
  <executions>
    <execution><id>flatten</id><phase>process-resources</phase><goals><goal>flatten</goal></goals></execution>
    <execution><id>flatten.clean</id><phase>clean</phase><goals><goal>clean</goal></goals></execution>
  </executions>
</plugin>

go deeper

for a junior

Knows it produces a resolved POM that gets published.

for a middle

Can configure it to fix ${revision} and add the clean execution.

for a senior

Chooses flattenMode by goal (CI-friendly vs OSS vs BOM) and uses it to decouple from an internal parent; verifies the published POM.

for a principal

Sets publication-POM policy across the org — what metadata to expose, parent-inlining, Central compliance, reproducibility.

## What 'flattening' means Your authored `pom.xml` is rich: it inherits from a parent, uses properties, has `<build>`, `<profiles>`, etc. Consumers of your artifact only need the parts relevant to **dependency resolution**. Flattening produces a single, self-contained POM with everything resolved and the irrelevant parts removed. ## How it works The plugin runs (typically in `process-resources`), writes `.flattened-pom.xml`, and with `updatePomFile=true` makes install/deploy use that file as the project's POM. ```xml <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>flatten-maven-plugin</artifactId> <version>1.6.0</version> <configuration> <flattenMode>oss</flattenMode> </configuration> <executions> <execution> <id>flatten</id><phase>process-resources</phase> <goals><goal>flatten</goal></goals> </execution> <execution> <id>flatten.clean</id><phase>clean</phase> <goals><goal>clean</goal></goals> </execution> </executions> </plugin> ``` ## flattenMode options (common ones) - `resolveCiFriendliesOnly` — only resolve `${revision}/${sha1}/${changelist}`; keep the rest. Minimal, used purely for CI-friendly versions. - `oss` — produces a clean POM acceptable for OSS/Maven Central (keeps name, description, url, licenses, scm, developers; drops build/profiles). - `bom` — tuned for publishing a Bill of Materials. - `clean`/`defaults` — other presets. ## When it's valuable beyond CI-friendly versions 1. **Removing the internal parent**: if you build with a corporate parent POM that you don't want to (or can't) publish, flattening inlines whatever is needed so the published artifact resolves without that parent. 2. **Lean consumer POM**: strips `<build>`, `<profiles>`, plugin config that consumers don't need, reducing confusion and accidental inheritance. 3. **Publishing a BOM** with resolved managed dependencies. 4. **Maven Central compliance**: `oss` mode keeps exactly the metadata Central requires. ## Gotchas - Always add the `clean` execution, or `.flattened-pom.xml` lingers. - Pick the mode deliberately: `resolveCiFriendliesOnly` keeps your POM nearly intact, while `oss`/`bom` aggressively prune — verify the published POM still lists the dependencies you expect.

  • Why might a library author flatten even without ${revision}?
    To inline an internal/corporate parent POM so the published artifact resolves standalone, and to strip build/profile noise consumers don't need.
  • What's the difference between resolveCiFriendliesOnly and oss mode?
    resolveCiFriendliesOnly only resolves the version placeholders and keeps the rest of the POM; oss aggressively prunes build/profiles while retaining metadata Maven Central requires.

Like exporting a layered design file to a flat PNG: consumers get the final rendered result, not your editable layers (parent, properties, profiles).

saying these in an interview costs you the question

  • Saying it modifies your source pom.xml in place (it writes a separate generated file)
  • Forgetting the clean execution so the generated POM lingers
  • Assuming one flattenMode fits all cases
  • Thinking it only matters for CI-friendly versions

context

resolving links…