gnodet opened a new pull request, #11780: URL: https://github.com/apache/maven/pull/11780
## Summary Addresses #11772 with a simpler approach than the previously closed dual consumer POM PR (#11775). ### Problem When consumer POM flattening is disabled and a project uses model version 4.1.0+ features (profile conditions, mixins, etc.), the consumer POM cannot be downgraded to 4.0.0, making it unreadable by Maven 3 and Gradle. The previous approach (dual consumer POMs with classifier-based parent resolution) was overly complex. ### Changes **1. `maven.consumer.pom.removeUnusedManagedDependencies` flag** New property (default: `true`) controlling whether unused managed dependencies are removed during consumer POM flattening. - **`true` (default)**: Managed dependencies not in the resolved dependency tree are removed, keeping consumer POMs lean. Important when using BOMs like Spring Boot or Quarkus with hundreds of managed entries. - **`false`**: All managed dependencies are preserved. Useful in rare cases where downstream consumers override transitive dependency versions and rely on the original managed dependencies for alignment (see #11346). This gives users control over the size vs. completeness tradeoff without changing the default behavior. **2. Consumer POM validation** Replaces the mixin-specific error check with a general validation: - **Non-flattened path**: When flattening is disabled and the consumer POM cannot be downgraded to 4.0.0, the build is rejected with actionable guidance: enable flattening, set `preserve.model.version=true`, or remove the incompatible features. - **POM-packaged projects**: Same validation applies when flattening is enabled, since parent POMs always keep their parent reference. Options are `preserve.model.version=true` or remove the features (flattening doesn't help for the parent POM itself). This is more general than the old mixin-only check — it catches any feature that prevents downgrade to 4.0.0 (mixins, profile conditions, etc.). ### Context See the discussion on #11772 for the full analysis of why this simpler approach was chosen over dual consumer POMs. Key points: - Maven 4 can already resolve the `build` classifier POM for full-fidelity parent resolution — no need for a separate consumer classifier - Flattening remains the primary mechanism for backward-compatible consumer POMs - The managed dep removal flag gives users an escape hatch for edge cases without changing defaults - Proper dependency alignment (import-scoped BOMs, enforced platforms) is the right long-term solution for the #11346 scenario ## Test plan - [x] Existing `ConsumerPomBuilderTest` unit tests pass - [x] Updated `MavenITgh11456MixinsConsumerPomTest` IT to match new error message - [x] All `maven-core` tests pass -- 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]
