gnodet opened a new pull request, #12625:
URL: https://github.com/apache/maven/pull/12625
## 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](https://lists.apache.org/thread/2s2myrg0zzk0q5z9kjhm8pwsntxmtnxh).**
## 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:
```xml
<!-- 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
- [x] New IT `MavenITBomConsumerPomPropertyResolutionTest` with 3 test
methods:
- `testBomConsumerPomResolvesParentProperties` — default (no-flatten) path
- `testBomConsumerPomWithFlattenResolvesParentProperties` — flatten=true
path
- `testConsumerPomInProjectLocalRepo` — verifies the `-consumer.pom`
artifact
- [x] All 4 existing BOM ITs pass (no regressions):
- `MavenITgh11427BomConsumerPomTest` (2 tests)
- `MavenITConsumerPomBomFromSettingsRepoTest` (1 test)
- `MavenITmng8293BomImportFromReactor` (1 test)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
