gnodet commented on issue #11772: URL: https://github.com/apache/maven/issues/11772#issuecomment-4029828664
@hboutemy Good question — you're right to revisit the flattening approach. The dual consumer POM approach is a **direct consequence** of not flattening child consumer POMs (i.e., keeping the `<parent>` reference). The chain of reasoning is: 1. **#11346** showed that flattening consumer POMs can lose "unused" managed dependencies that downstream consumers actually need (when they override a transitive dependency version, bringing in new transitive deps that the removed management would have controlled) 2. The response was to **stop flattening** — keep the `<parent>` reference in consumer POMs 3. But keeping `<parent>` means the parent POM must be resolvable from the repository 4. If the parent uses 4.1.0 features and only a stripped 4.0.0 consumer POM is published, Maven 4 consumers lose those features 5. Hence **dual consumer POMs** — publish both a 4.0.0 stripped version and a 4.1.0 full-fidelity version ### Alternatives We could avoid dual consumer POMs entirely if we go back to flattening. This is possible if either: 1. **Fix managed dep removal separately**: stop filtering "unused" managed dependencies during flattening. This fixes the root cause of #11346 while keeping consumer POMs self-contained and 4.0.0-compatible. The `<parent>` reference is dropped, everything is inlined, no parent resolution needed. 2. **Accept the managed dep loss**: keep flattening as-is, acknowledging that some edge cases (#11346 scenario) may break. This is the simplest approach but has known issues. ### Flattening vs. non-flattening trade-offs | | Flatten (drop parent) | Non-flatten (keep parent) | |---|---|---| | Consumer POM size | Larger (all content inlined) | Smaller (inherits from parent) | | Parent resolution | Not needed | Required → dual consumer POMs for 4.1.0+ parents | | #11346 managed deps | Need fix (stop removing "unused" managed deps) | Not an issue (inheritance preserved) | | Complexity | Simpler deployment (one consumer POM) | More complex (two consumer POMs + classifier resolution) | | Future model versions (mixins etc.) | Works — mixin content resolved at build time and inlined | Works — mixin references preserved in full-fidelity POM | ### My take The simplest path forward might be: - **Fix #11346 at its root** (stop removing unused managed deps during flattening) as a separate PR - **Flatten consumer POMs** (drop `<parent>`, inline everything) — as was originally designed - **No dual consumer POMs needed** The dual consumer POM approach in PR #11775 solves the problem but introduces significant complexity (classifier-based parent resolution, dual artifact deployment, model schema changes). If we can fix managed dep removal, the original flattening approach handles everything including future model versions like 4.2.0 mixins — since mixin content is resolved at build time and inlined into the flattened consumer POM. What are your thoughts on the flattening + fix managed dep removal approach? -- 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]
