gnodet opened a new issue, #11346: URL: https://github.com/apache/maven/issues/11346
## Summary Currently, Maven's consumer POM transformation flattens dependency management sections by default, which prevents dependency management from being inherited by consumers. This creates issues in scenarios where transitive dependency management inheritance is desired. ## Use Case Consider the following dependency scenario: - **Module A 1.0**: depends on B 1.0 and manages C to version 1.2 - **Module B 1.0**: has no dependencies - **Module B 2.0**: depends on C 1.1 - **Module D**: depends on A 1.0 and manages B to version 2.0 ### Expected Behavior When Module D builds, it should resolve: - B 2.0 (due to D's dependency management override) - C 1.2 (due to A's dependency management, which should take precedence over B 2.0's direct dependency on C 1.1) ### Current Problem With consumer POM flattening enabled (default), Module A's consumer POM loses its dependency management section. This means when Module D consumes A 1.0, the dependency management for C 1.2 is not available, and Module D ends up with C 1.1 from B 2.0's direct dependency. ### Desired Solution A feature flag (e.g., `maven.consumer.pom.flatten=false`) that allows disabling consumer POM flattening, preserving dependency management sections in consumer POMs so they can be inherited by downstream consumers. ## Integration Test This use case is demonstrated by the integration test `MavenITDependencyManagementOverrideTest` which: 1. Sets up the multi-module scenario described above 2. Verifies that with flattening disabled, Module D correctly resolves C 1.2 instead of C 1.1 3. Confirms that dependency management inheritance works as expected when consumer POMs preserve their dependency management sections ## Alternative Workarounds While `-Dmaven.resolver.dependencyManagerTransitivity=false` can achieve similar results in some cases, it works at the resolver level and may have broader implications. The consumer POM flattening control provides a more targeted solution that specifically addresses the POM transformation behavior. ## Benefits 1. **Backward Compatibility**: Maintains current default behavior while providing opt-in control 2. **Dependency Management Inheritance**: Enables proper transitive dependency management scenarios 3. **Flexibility**: Allows projects to choose the appropriate consumer POM strategy based on their needs 4. **Clear Semantics**: Provides explicit control over whether consumer POMs should behave like parent POMs (preserving dependency management) or be flattened for simpler consumption This feature would be particularly valuable for library authors who need their dependency management to be inherited by consumers, and for complex multi-module projects where transitive dependency management is crucial for maintaining consistent dependency versions across the dependency graph. -- 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]
