| name | verify-pom-refactor |
| description | Verify that a change to any pom.xml did not silently alter build behaviour. Use whenever a POM is restructured, a plugin or dependency is moved between sections, or a pluginManagement/dependencyManagement entry is pruned — Maven's model merging can change what executes with no visible symptom. |
Verifying a POM refactor
Maven's model merging is implicit enough that a POM change can alter behaviour with no visible symptom — that is the
common thread through the 4.0.1 obfuscation regression, the silent zero-test Failsafe run, and the parent POM
inlining. For any structural POM change, diff the effective POM rather than reading the source diff:
for m in . api build-tasks core jax-rs jsf maven-plugin obfuscate spi swing tests ui v1 v2-core v2-json v2-xml v4; do
n=$(echo "$m" | sed 's|^\.$|ROOT|')
for p in plain release; do
[ "$p" = release ] && PF="-P sonatype-oss-release" || PF=""
./mvnw -o -q help:effective-pom -pl "$m" $PF -Doutput="$DIR/$n.$p.xml"
done
done
Strip the Generated by Maven Help Plugin on line (it carries a timestamp), capture before and after, and diff. Two
things make the result readable:
- A pure reordering is not a behaviour change unless two plugins share a phase. Check with
diff <(sort before) <(sort after): if that is empty, only the order moved.
- Inherited-but-inactive profiles are invisible.
help:effective-pom lists a project's own profiles and
injects the active ones into <build>; profiles inherited from an ancestor are not listed at all, which is why
module effective POMs have no <profiles> section. So a profile moving between POMs shows up as a large
<profiles> addition on the declaring project and nothing anywhere else. Diff the <build> section separately —
that is what actually executes.
The inlining commit was signed off on exactly this: all 32 module effective POMs content-identical, one adjacent
transposition (truelicense-maven-plugin ↔ maven-antrun-plugin, phases process-classes vs prepare-package) in
the release-profile ones, and the root's <build> unchanged. Profile declaration order in the root POM is arranged
to reproduce the old parent-then-child injection order for that reason, and for no other.
Then confirm against artifacts, not the log — ./mvnw -o clean install -P sonatype-oss-release -Dgpg.skip=true -Dmaven.javadoc.skip=true, followed by the grep -rlaE '_clinit@|_string#' check under Build-time verification
in CLAUDE.md.
Pruning
For a prune, where the effective POM is supposed to change, invert the check: assert that the things which
must not move, didn't. Two comparisons cover it, and both caught nothing only because the prune was scoped from
evidence rather than from reading:
- Resolved version of every plugin that executes a goal. Extract the
<artifactId>/<version> pairs from the
<build><plugins> section of all 34 effective POMs and diff the sorted set. Removing a pluginManagement entry
for a plugin that turns out to be bound somewhere silently downgrades it to a lifecycle default.
- Full GAV and scope of every resolved dependency.
./mvnw -o dependency:list over the reactor, before and
after, diffed. Removing a dependencyManagement entry can shift a transitive version even when no module
declares that artifact directly. On the prune commit the only delta was ScalaCheck and its test-interface
leaving the test classpath, which was the intent.
