gnodet commented on issue #7209:
URL: https://github.com/apache/maven/issues/7209#issuecomment-6662201555

   After discussion, I believe the approach proposed in #13663 is not the right 
direction. The fundamental problem is that `import` scope is not a "real" 
dependency scope — it is a build-time directive that tells the model builder to 
expand a BOM's `dependencyManagement` in-place. The effective model is by 
definition the **resolved** model: keeping `import`-scoped entries in it 
creates a semantic invariant violation that every consumer of the effective 
model (resolver, plugins, tooling) would have to guard against.
   
   The use case described — detecting which BOMs were imported and at which 
version — is real and valid. However the right tools for this are already 
available:
   
   1. **The raw/file model** still contains the original `import`-scoped 
entries untouched. Any tool that needs to know which BOMs were imported can 
read the raw model alongside the effective model. This is exactly the approach 
taken by [maveniverse/toolbox's 
`doCollectDmRecursive`](https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxResolverImpl.java#L716-L745),
 which uses 
[`MavenModelReader`](https://github.com/maveniverse/mima/blob/main/extensions/mmr/src/main/java/eu/maveniverse/maven/mima/extensions/mmr/ModelResponse.java)
 to get both `getRawModel()` and `getEffectiveModel()`, then walks the lineage 
to reconstruct BOM provenance without touching the effective model.
   
   2. **Location API** — each managed dependency in the effective model carries 
location information tracing it back to its source, which can be used to infer 
BOM origin.
   
   For the release-guard use case specifically: a plugin can call 
`project.getModel()` (file model, pre-import-expansion) to find the 
`import`-scoped entries, then validate their versions from there — no changes 
to Maven core needed.
   
   Closing this issue as "not planned".
   


-- 
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]

Reply via email to