gnodet commented on issue #11772: URL: https://github.com/apache/maven/issues/11772#issuecomment-4032266114
Following up on the discussion — after more analysis, we are closing the dual consumer POM PR (#11775). Here is why and what we propose instead. ### Why dual consumer POMs are unnecessary Maven already deploys the original POM with a `build` classifier. If Maven 4 needs full-fidelity parent resolution, it can resolve the build POM. There is no need for a third artifact (consumer classifier POM) with its own resolution mechanism (`<classifier>` on `<parent>`). Furthermore, the PR description claimed that "stripping is a dead end because of mixins (4.2.0)." But this is flawed reasoning — mixins cannot be stripped without losing content regardless, so the 4.0.0 backward-compatible POM **must** be flattened (mixin content resolved and inlined). The dual consumer POM approach does not avoid flattening for mixins either. ### Revised proposal The actual fixes needed are simpler: **1. Flag for managed dependency removal during flattening** Currently, "unused" managed dependencies are removed during consumer POM flattening to keep POMs lean (important when using BOMs like Spring Boot or Quarkus with hundreds of managed entries). This should be controllable via a property (e.g., `maven.consumer.pom.removeManagedDependencies`), defaulting to `true` (current behavior). Users who hit the #11346 edge case can set it to `false`. Note: we consider #11346 an edge case, not a bug. Relying on managed deps leaking through transitive dependency POMs is fragile and implicit. Proper dependency alignment (import-scoped BOMs, enforced platforms) is the right solution for that use case. **2. Build validation when flattening is disabled** If a user disables flattening (`maven.consumer.pom.flatten=false`) and their parent POM uses 4.1.0+ features that cannot be represented in a non-flattened consumer POM (since the parent reference would point to the stripped 4.0.0 parent, losing features), Maven should **reject the build** with a clear error message explaining that flattening must be enabled. This prevents silent loss of consuming-time information without requiring the complexity of dual consumer POMs. **3. Consider re-enabling flattening as default** Flattening was disabled in response to #11346, but if we treat that as an unsupported use case (dependency alignment should be explicit), flattening could be re-enabled as the default, keeping consumer POMs lean and self-contained. ### Summary | Approach | Complexity | Backward compat | Maven 4 full-fidelity | POM size | |---|---|---|---|---| | ~~Dual consumer POMs~~ | High (new classifier, resolution logic, schema changes) | Yes | Yes (via consumer classifier) | Small | | **Flatten + flag + validation** | Low (flag + validation check) | Yes (flattened 4.0.0) | Yes (via build classifier) | Lean (with removal) or larger (without) | The second approach achieves the same goals with far less complexity. -- 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]
