gnodet commented on issue #11772:
URL: https://github.com/apache/maven/issues/11772#issuecomment-4026710663
## Proposed Solution: Dual Consumer POMs with Classifier-Based Parent
Resolution
### Core Idea
Deploy **two** consumer POMs for POM-packaged projects (parents):
| Artifact | Model Version | Content | Consumer |
|---|---|---|---|
| Main POM (no classifier) | **4.0.0** | 4.1.0 features stripped, parent
reference kept (pointing to parent's main POM, also 4.0.0) | Maven 3, Gradle,
other tools |
| `consumer` classifier | **4.1.0** | Full-fidelity consumer POM with all
features preserved, parent reference pointing to parent's `consumer` classifier
| Maven 4 |
| `build` classifier | 4.1.0 | Original build POM (unchanged from today) |
Maven 4 builds |
### How It Works
**For POM-packaged projects (parents)**, during consumer POM generation:
1. **Main POM (4.0.0)**: `transformPom()` aggressively strips **all**
remaining 4.1.0 features from the consumer POM:
- Profile activation `condition` → stripped or converted to legacy
activation
- Profile activation `packaging` → stripped
- Extension `configuration` → stripped
- Build `sources` → stripped
- Force model version to 4.0.0
- **Keep the `<parent>` reference as-is** — this is safe because the
parent's main POM follows the same convention and is also 4.0.0
2. **Consumer classifier POM (4.1.0)**: the current consumer POM output,
unchanged, preserving all features. The `<parent>` element references the
parent's `consumer` classifier.
**For non-POM projects** (jars, etc.): behavior is unchanged — parent is
already stripped (`parent(null)`), model version already downgraded to 4.0.0.
### Maven 4 Parent Resolution
Maven 4 needs to support classifier-based parent resolution:
- Add `<classifier>` support to the `<parent>` element in the 4.1.0+ model
- The `consumer` classifier POM uses
`<parent><classifier>consumer</classifier></parent>` to reference the parent's
full-fidelity consumer POM
- The main (4.0.0) POM has no classifier on its parent — Maven 3 resolves it
normally
This keeps the POM self-describing: any tool reading the POM knows exactly
which artifact to resolve, without relying on implicit resolution conventions.
### Why This Avoids the Flattening Problem (#11346)
The main (4.0.0) POM is **not flattened** — it does not inline parent
inheritance or modify dependency management. It only strips 4.1.0 model
features that Maven 3 cannot understand. The `<parent>` reference and
dependency management inheritance chain remain intact, so the dependency
management "depth" is unchanged and #11346 does not apply.
Maven 3 consumers lose access to 4.1.0-specific features (profile
conditions, extension configuration, etc.), but these features were never
supported by Maven 3 in the first place.
### What Needs to Change
1. **POM Model (4.1.0)**: Add optional `<classifier>` to `<parent>` element
2. **`DefaultConsumerPomBuilder`**: Generate two consumer POMs for
POM-packaged projects — one with features stripped (4.0.0), one with full
fidelity (4.1.0, referencing parent's `consumer` classifier)
3. **`ConsumerPomArtifactTransformer`**: Deploy both consumer POMs with
appropriate classifiers
4. **Maven 4 parent resolution** (`DefaultModelBuilder` / resolver): Support
resolving parent POMs with a classifier
5. **`MavenModelVersion`**: Ensure the 4.0.0 variant passes the version
check after all 4.1.0 features are stripped
### Limitations
- **Existing artifacts**: Projects already deployed with 4.1.0 parent POMs
(like JLine 4.0.0) would need a re-release to benefit from this fix
- **Feature loss for Maven 3**: Maven 3 consumers of a Maven 4-built parent
lose 4.1.0-only features (profile conditions, etc.) — this is an acceptable
trade-off since Maven 3 never supported them
--
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]
