[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152910#comment-15152910
]
Christian Schulte commented on MNG-5971:
----------------------------------------
It's a technical restriction. The very purpose of the {{include}} scope is to
be processed before inheritance. This is what this issue is about. The
{{import}} scope is implemented in a way that it is one of the last steps
involved during model building. After inheritance processing, property
substitution, path normalisation etc. (when the model already is completely
built). That's what has lead to this issue and that's why you can use
properties for the {{import}} scope. For the {{include}} scope, the following
currently would not be possible.
{code}
<dependency>
<groupId>${groupId.property}</groupId>
<artifactId>${artifactId.property}</artifactId>
<version>${version.property}</version>
<scope>include</scope>
<type>pom</type>
</dependency>
{code}
The values for these properties need to be available during reading the model
before any further processing takes place. If it will be released that way, it
will not take long until the first issue is filed stating that is a bug. I
haven't found a way to make that work without breaking the very purpose of the
{{include}} scope yet. Building the complete model once to remember the values
to be used for the {{include}} scope to then start the model building over
again with those values may be solution. Inheritance processing would need to
be re-implemented to support only processing properties.
> Imported dependencies should be available to inheritance processing
> -------------------------------------------------------------------
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Wish
> Components: Dependencies
> Affects Versions: 3.3.3
> Reporter: Stephane Nicoll
> Priority: Trivial
>
> When a project extends from a parent with a {{dependencyManagement}} section,
> it is not always possible to properly override (and align) the version to use
> for a group of dependencies.
> We typically use Bill Of Materials to gather a group of modules and make sure
> their versions are consistent.
> The following project demonstrates the issue:
> https://github.com/snicoll-scratches/maven-dependency-management
> The first commit is a working use case where the parent uses a bom with
> version A and we use the same bom with version B in the child. Version B is
> used as expected.
> The second commit demonstrates the faulty scenario. Rather than using a bom
> in the parent, we use a direct dependency (provided by that bom). We still
> use the bom with a different version. In that case all the dependencies but
> the one provided by the parent are overridden (leading to mixed versions for
> the dependencies provided by the BOM).
> It looks like the distance is still used to compute the version while the
> graph of dependencies should be flatten at each step for a proper override.
> Thoughts? Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
