Hiteshsai007 commented on PR #12417: URL: https://github.com/apache/maven/pull/12417#issuecomment-4886557923
@elharo Thank you for the review. That is a very fair point, and I completely understand the hesitation. Changing the semantics of BOM imports to include `<properties>` is a significant shift, and backwards compatibility / stability is paramount. To provide some context on the motivation: this was implemented to address [MNG-8432 / #10196](https://github.com/apache/maven/issues/10196). It's a frequent pain point for users (as seen in this [StackOverflow thread with 10k+ views](https://stackoverflow.com/questions/45963173/import-maven-property-used-in-bill-of-materials-bom)). Currently, if a project imports a BOM to manage dependency versions, but needs to use one of those versions for a plugin configuration (like `maven-dependency-plugin`), the user is forced to manually duplicate the property in their child POM, breaking the single-source-of-truth that the BOM is supposed to provide. To mitigate the "unforeseen consequences", I've implemented a safeguard in this PR: * **Consumer Precedence**: Properties defined locally in the consuming project always take precedence over imported BOM properties. This prevents a BOM from silently overriding a project's explicitly defined properties. However, I understand there are still risks (e.g., conflicting properties if multiple BOMs are imported). How would you prefer to handle this design decision? A few potential options: 1. **Feature Flag**: Would you be more comfortable if this was opt-in? (e.g., requiring a specific attribute on the dependency or a Maven CLI flag). 2. **Mailing List**: Should I start a thread on the `[email protected]` mailing list to gather broader consensus on this feature before we proceed? 3. **Specific Test Cases**: Are there specific edge-case scenarios or reactor setups you'd like me to write integration tests for to prove it behaves predictably? I'm happy to take this in whatever direction the core team feels is safest. -- 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]
