[MNG-8432] Inherit properties from imported BOMs

[Hiteshsai007]

[MNG-8432] Inherit properties from imported BOMs

fixes #10196

Description

This PR resolves MNG-8432 (also referenced as #10196 on GitHub), which adds the capability to inherit properties from imported BOMs.

Previously, when a child project imported a BOM using <dependencyManagement> with <scope>import</scope>, Maven only extracted and merged the <dependencyManagement> sections. The <properties> block of the BOM was entirely ignored. This limitation forced users to manually duplicate property definitions (e.g., version placeholders) in their consuming POMs to use them in plugins or standard dependencies.

Changes in this PR:

1. Model Loading: Modified DefaultModelBuilder.loadBomModel to fetch and return the complete resolved Model of the BOM rather than just the DependencyManagement object.
2. Property Extraction: Updated importDependencyManagement to collect the properties from all imported BOM models and merge them into the consuming model. The consuming model's existing properties take precedence, preventing unwanted overrides.
3. Re-Interpolation Pass: Because importDependencyManagement runs after the initial model interpolation pass (readEffectiveModel), added a second pass of interpolateModel(resultModel, request, this) immediately after importing the properties. This correctly substitutes BOM properties into the unresolved placeholders (e.g., <version>${lib.version}</version>) within the model.

Checklist

• Your pull request addresses just one issue, without pulling in other changes.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request has a meaningful subject line and body.
• The core Maven IT suite and unit tests run successfully against this change.

[elharo]

I'm not yet convinced this is a feature we want. It could have unforeseen consequences. care is warranted.

[Hiteshsai007]

@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. It's a frequent pain point for users (as seen in this StackOverflow thread with 10k+ views). 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 dev@maven.apache.org 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.