Fix BOM consumer POM leaving property references unresolved

[gnodet]

Summary

Fixes the BOM consumer POM builder leaving ${...} property references unresolved when consumer POM flattening is disabled (the default).

Reported by Karl Heinz Marbaise during the 4.0.0-rc-6 vote.

Problem

DefaultConsumerPomBuilder.buildBomWithoutFlatten() used getRawModel() (no interpolation), but then transformBom() strips both the parent and properties sections. The result is a consumer POM with dangling property references that no consumer can resolve.

Example — a BOM with ${junit.version} defined in its parent produced this consumer POM:

<!-- No groupId, no version, no properties, no parent -->
<project>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>bom</artifactId>
  <packaging>pom</packaging>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>${junit.version}</version>   <!-- unresolvable! -->
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

Scope of breakage

This affects virtually all real-world BOMs on the default (no-flatten) code path:

Scenario	Broken?
Property-referenced dependency versions (${junit.version})	✅ Yes — dangling ${...}
${project.version} in dependency versions	✅ Yes — dangling
CI-friendly ${revision}	✅ Yes — dangling
Inherited groupId / version from parent	✅ Yes — missing entirely
Standalone BOM with all literal versions, own groupId/version	❌ No — but this is extremely rare

Root cause

The buildBomWithoutFlatten() method (introduced in #11427) was modeled after buildPom() which also uses getRawModel(). But transformPom() preserves the parent reference and properties (so consumers can resolve ${...} by reading the parent), while transformBom() strips them (BOMs are self-contained). Using getRawModel() with a parent-stripping transform is fundamentally incompatible.

Fix

• Route all BOMs through buildBom() which uses getEffectiveModel() (fully interpolated)
• Delete the now-dead buildBomWithoutFlatten() method

The flatten flag has no semantic effect on BOMs because transformBom() always strips parent and properties to produce a self-contained POM, regardless of the flag. The distinction only matters for regular POM packaging (where no-flatten preserves the parent reference).

Before → After

Field	Before (broken)	After (fixed)
groupId	missing	org.apache.maven.its.bom-property
version	missing	1.0.0-SNAPSHOT
junit version	${junit.version}	4.13.2

Test plan

• New IT MavenITBomConsumerPomPropertyResolutionTest with 3 test methods:
  • testBomConsumerPomResolvesParentProperties — default (no-flatten) path
  • testBomConsumerPomWithFlattenResolvesParentProperties — flatten=true path
  • testConsumerPomInProjectLocalRepo — verifies the -consumer.pom artifact
• All 4 existing BOM ITs pass (no regressions):
  • MavenITgh11427BomConsumerPomTest (2 tests)
  • MavenITConsumerPomBomFromSettingsRepoTest (1 test)
  • MavenITmng8293BomImportFromReactor (1 test)

🤖 Generated with Claude Code

[gnodet]

LGTM ✅

Clean, well-motivated bugfix for a real and severe issue (dangling ${...} in BOM consumer POMs) reported during the Maven 4.0.0-rc-6 vote. The two-line code change is correct, the dead-code removal is safe (no subclasses, no other callers), and the new integration test provides thorough coverage of the fix.

Details:

• The root-cause analysis is accurate: buildBomWithoutFlatten() used getRawModel() (uninterpolated), and then transformBom() stripped parent and properties via prune(), leaving dangling ${...} references. Routing all BOMs through buildBom() (which uses getEffectiveModel()) is the correct fix.
• The removed buildBomWithoutFlatten() method has no subclass overrides and only one call site, so the removal is safe.
• The new integration test covers all three relevant paths: default/no-flatten, flatten=true, and project-local-repo consumer POM.
• The existing test did not catch this bug because it only checked packaging and <dependencyManagement>, not property resolution. The new test fills that gap.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

[github-actions]

@gnodet Please assign appropriate label to PR according to the type of change.