maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schulte (JIRA)" <>
Subject [jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
Date Fri, 19 Feb 2016 21:55:18 GMT


Christian Schulte commented on MNG-5971:

I am copying the comment of the last commit here.

o Updated to remove the 'include' scope. Everyone agrees to the 'import' scope
  being broken the way it got implemented in Maven 2.0.x and to need fixing
  according to the description of the issue.
o Updated to remove support of 'import' and 'include' scopes of dependencies.
  Currently there are issues with the way Maven normalizes redundant
  dependencies to be backwards compatible to Maven 2. Import of dependencies
  cannot be implemented consistently with this backwards compatibility in place.
o Updated to fix the 'import' scope to behave as requested in MNG-5971.

So a recent [3.4.0-SNAPSHOT|]
will have the fixed {{import}} scope. Please download and test the {{import}} scope is working
correctly now.

> Imported dependencies should be available to inheritance processing
> -------------------------------------------------------------------
>                 Key: MNG-5971
>                 URL:
>             Project: Maven
>          Issue Type: Wish
>          Components: Dependencies
>    Affects Versions: 3.3.3
>            Reporter: Stephane Nicoll
>            Assignee: Christian Schulte
>            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:
> 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

View raw message