[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16286168#comment-16286168
]
Hudson commented on MNG-5971:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » pre-reset-master #3
See https://builds.apache.org/job/maven-wip/job/maven/job/pre-reset-master/3/
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> 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.4.14#64029)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15942026#comment-15942026
]
Christian Schulte commented on MNG-5971:
Issue is fixed in the master branch of [my private maven repository on
github|https://github.com/ChristianSchulte/maven/tree/master]. When interested,
you can cherry pick the commit to your own repository and create a pull request
for the apache master branch with just this commit yourself from there.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Priority: Trivial
> Fix For: 3.6.0-candidate
>
> Attachments: bom-cloud.zip
>
>
> 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.15#6346)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743962#comment-15743962
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #33 (See
[https://builds.apache.org/job/maven-3.x%20Jigsaw/33/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 96a55023e22f185eebbf868d6660d363870d3e68)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743943#comment-15743943
]
Hudson commented on MNG-5971:
-
FAILURE: Integrated in Jenkins build maven-3.x #1435 (See
[https://builds.apache.org/job/maven-3.x/1435/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 96a55023e22f185eebbf868d6660d363870d3e68)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741021#comment-15741021
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #30 (See
[https://builds.apache.org/job/maven-3.x%20Jigsaw/30/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 2858fd32d7b58255ecf487325eff68db99a2909e)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741022#comment-15741022
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1431 (See
[https://builds.apache.org/job/maven-3.x/1431/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 2858fd32d7b58255ecf487325eff68db99a2909e)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15740744#comment-15740744
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #29 (See
[https://builds.apache.org/job/maven-3.x%20Jigsaw/29/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev ee4fcfd547cdec357e05c1fa8da36f0c5138e4e9)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15740745#comment-15740745
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1430 (See
[https://builds.apache.org/job/maven-3.x/1430/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev ee4fcfd547cdec357e05c1fa8da36f0c5138e4e9)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15738375#comment-15738375
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1425 (See
[https://builds.apache.org/job/maven-3.x/1425/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 121d987a42df864445e297e99e97ea83415e7a38)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 8e0b9838a826d36ec18cfffce5e2273fff88cffa)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15738376#comment-15738376
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #24 (See
[https://builds.apache.org/job/maven-3.x%20Jigsaw/24/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 121d987a42df864445e297e99e97ea83415e7a38)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 8e0b9838a826d36ec18cfffce5e2273fff88cffa)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15738332#comment-15738332
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1424 (See
[https://builds.apache.org/job/maven-3.x/1424/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 5785d6f1dc7c494445eedc49a537c5537ede8865)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15738326#comment-15738326
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x Jigsaw #23 (See
[https://builds.apache.org/job/maven-3.x%20Jigsaw/23/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 5785d6f1dc7c494445eedc49a537c5537ede8865)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15490488#comment-15490488
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1372 (See
[https://builds.apache.org/job/maven-3.x/1372/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev a2d2bbb86bac94a890785a8d9410dd47db10385f)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15429239#comment-15429239
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in Jenkins build maven-3.x #1366 (See
[https://builds.apache.org/job/maven-3.x/1366/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev eaa4cdfb8e2f32306b425ecad68fde25f21271fa)
* (edit)
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420109#comment-15420109
]
Hudson commented on MNG-5971:
-
FAILURE: Integrated in maven-3.x #1363 (See
[https://builds.apache.org/job/maven-3.x/1363/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 2e6fe1bf3c32fd4b6ab5ca3068c1773c73519fe9)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelProblem.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420104#comment-15420104
]
Hudson commented on MNG-5971:
-
FAILURE: Integrated in maven-3.x #1362 (See
[https://builds.apache.org/job/maven-3.x/1362/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev df7e29b9d60091879fb6c485aa5fa7ac415737ae)
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420098#comment-15420098
]
Hudson commented on MNG-5971:
-
FAILURE: Integrated in maven-3.x #1361 (See
[https://builds.apache.org/job/maven-3.x/1361/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 059b9ab3028360b011c1539caa4c40d033b9143f)
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelProblem.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingRequest.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419821#comment-15419821
]
Stephane Nicoll commented on MNG-5971:
--
That project is quite complicated, it would be nice if you could focus on the
things you are complaining (like I did with a super simple project structure).
The point in this issue is that anything that a child defines should override
the parent. If you put the dependency directly in the child, it will override
the version of the parent. If you import a BOM, it must do the same for
consistency reason. Are we arguing that principle or are you referring to
something else?
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419681#comment-15419681
]
Hudson commented on MNG-5971:
-
FAILURE: Integrated in maven-3.x #1360 (See
[https://builds.apache.org/job/maven-3.x/1360/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 814b5166123c54b21545038038536063ce8dba1c)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15419236#comment-15419236
]
Curtis Rueden commented on MNG-5971:
This change breaks backwards compatibility, and IMHO should be reverted.
h1. REAL-WORLD EXAMPLE
Consider the following project:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml
Amongst many other dependencies, this project has:
{code:xml}
ca.mcgill
Sholl_Analysis
runtime
{code}
This is defined in the parent sc.fiji:pom-fiji:24.1.0 here:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L830-L835
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L255-L256
{code:xml}
3.6.2
...
ca.mcgill
Sholl_Analysis
${Sholl_Analysis.version}
{code}
With Maven 3.3.9, we have:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.2:runtime
{code}
But with Maven 3.4.0-20160806.181437-172, we get:
{code}
$ mvn dependency:list|grep Sholl
[INFO]ca.mcgill:Sholl_Analysis:jar:3.6.1:runtime
{code}
!!!
I believe this surprising behavior is caused by the fact that the toplevel fiji
POM needs to also include other BOMs via import scope:
*
https://github.com/fiji/fiji/blob/ced9faee1c4fba9997a3d614759fb6e78e359d4f/pom.xml#L49-L68
{code:xml}
sc.fiji
pom-bigdataviewer
${pom-bigdataviewer.version}
pom
import
sc.fiji
pom-trakem2
${pom-trakem2.version}
pom
import
{code}
The version of pom-bigdataviewer is 3.2.0:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-24.1.0/pom.xml#L135-L136
Which extends pom-fiji version 22.3.0 instead of 24.1.0:
*
https://github.com/bigdataviewer/pom-bigdataviewer/blob/pom-bigdataviewer-3.2.0/pom.xml#L5-L9
And that version of pom-fiji defines Sholl_Analysis at 3.6.1 instead:
* https://github.com/fiji/pom-fiji/blob/pom-fiji-22.3.0/pom.xml#L261-L262
h1. GIST OF THE PROBLEM
So, with Maven 3.4.0, dependency management brought in from import scope is now
trumping that brought in from the parent POM itself. This is problematic
because:
* IMHO, it violates the Principle of Least Astonishment.
* It is now more complicated to compose together multiple "subtrees" of
components into a final application which needs to inherit multiple BOMs from
these subtrees.
* It is now not possible to override version properties _in the POM itself_ to
trump the dependencyManagement versions.
* But strangely, you _can_ still override the version property on the CLI via
-DSholl_Analysis.version=x.y.z. This seems inconsistent.
I understand and appreciate that I am naive of the deepest nuances of the Maven
project model and how it gets synthesized. But:
# The above behavior will break all of my projects.
# I do not know how to restructure my components for Maven 3.4.0 to avoid this
problem.
My vote would be to revert to the old behavior, which seems better to me.
However, if this behavior really must be changed, I would suggest pushing it
till Maven 4, since it will surely break a lot of existing builds.
If this change really goes through, then all previous releases of all of my
projects will no longer build reproducibly with Maven 3.4.0+, since they will
produce different dependency graphs.
Rather than breaking backwards compatibility of import scope by default,
perhaps there could be a setting, or a different scope as Christian Schulte
previously suggested.
See also this thread on the maven-users list:
*
http://mail-archives.apache.org/mod_mbox/maven-users/201608.mbox/%3CCADN69yn-ffoEV6_Q24VXAcSKbdXrT6CL263ih-LvvEdoYmL4CA%40mail.gmail.com%3E
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority:
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15322156#comment-15322156
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1294 (See
[https://builds.apache.org/job/maven-3.x/1294/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev a6d52372afddb56a5ca6cc1ef095c32f622eddb6)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15183193#comment-15183193
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1253 (See
[https://builds.apache.org/job/maven-3.x/1253/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 4bdb16c93afd8f2742003c286f65751c55a86c3c)
* maven-model-builder/src/site/apt/index.apt
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15163816#comment-15163816
]
Christian Schulte commented on MNG-5971:
Please take a look at MNG-5947. It's about changing the "first declaration wins
strategy" to "nearest declaration wins". I think this is contentious.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159522#comment-15159522
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1244 (See
[https://builds.apache.org/job/maven-3.x/1244/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 4ae1673484c66e6125a91463cb517237933a3437)
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159502#comment-15159502
]
Christian Schulte commented on MNG-5971:
That's been intentional. This should have made you resolve the conflicts
manually by moving the conflicting imports up or down the inheritance hierarchy
so that the inheritance override logic based on Maven coordinates would be used
to resolve conflicts. The latest commit reverts to the former behaviour without
producing such warnings. You should still use the inheritance hierarchy for
overriding dependencies. I understand this has not been possible pre 3.4 and
you cannot use it without enforcing Maven >= 3.4 because it simply will not
work with anything pre 3.4.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159039#comment-15159039
]
Christian Schulte commented on MNG-5971:
Those warnings would appear if declared directly. That's the point. I
understand people rely on the override logic based on the order of elements.
There has not been another way to do that. You could do it smarter starting
with 3.4. I understand the former behaviour needs to be restored. I'll need to
add integration tests for this. If so many people rely on that, this really
should be captured in an IT.
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
localhost
MNG-5971
1-SNAPSHOT
pom
org.springframework
spring-aop
4.2.4.RELEASE
org.springframework
spring-aop
4.2.3.RELEASE
{code}
{code}
Apache Maven 3.3.9 (8512d6f051da85fdd21c8c1f939f3aac2ae287c2;
2015-11-19T00:20:09+01:00)
Maven home: /home/schulte/Applications/apache-maven-3.3.9
Java version: 1.8.0_45, vendor: Oracle Corporation
Java home: /usr/local/jdk-1.8.0/jre
Default locale: en_DE, platform encoding: UTF-8
OS name: "openbsd", version: "5.8", arch: "amd64", family: "unix"
{code}
{code}
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
localhost:MNG-5971:pom:1-SNAPSHOT
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.springframework:spring-aop:jar -> version 4.2.4.RELEASE vs
4.2.3.RELEASE @ line 17, column 19
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
{code}
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15159004#comment-15159004
]
Stephane Nicoll commented on MNG-5971:
--
{noformat}
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.example:demo:jar:0.0.1-SNAPSHOT
[WARNING] Multiple conflicting imports of dependency
'org.springframework.integration:spring-integration-http:jar' into model
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' ('101 : 19,
org.springframework.integration:spring-integration-bom:4.2.4.RELEASE
/Users/snicoll/.m2/repository/org/springframework/integration/spring-integration-bom/4.2.4.RELEASE/spring-integration-bom-4.2.4.RELEASE.pom',
'1803 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom').
To resolve this conflict, either declare the dependency directly in model
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' to override what gets
imported or rearrange the causing imports in the inheritance hierarchy to apply
standard override logic. Without resolving this conflict, your build relies on
indeterministic behaviour. @
org.springframework.cloud:spring-cloud-dependencies:Brixton.M5
[WARNING] Multiple conflicting imports of dependency
'org.apache.httpcomponents:httpclient:jar' into model
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' ('103 : 16,
org.springframework.cloud:spring-cloud-consul-dependencies:1.0.0.M6
/Users/snicoll/.m2/repository/org/springframework/cloud/spring-cloud-consul-dependencies/1.0.0.M6/spring-cloud-consul-dependencies-1.0.0.M6.pom',
'1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
'1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
'1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
'1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
'1071 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom').
To resolve this conflict, either declare the dependency directly in model
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' to override what gets
imported or rearrange the causing imports in the inheritance hierarchy to apply
standard override logic. Without resolving this conflict, your build relies on
indeterministic behaviour. @
org.springframework.cloud:spring-cloud-dependencies:Brixton.M5
[WARNING] Multiple conflicting imports of dependency
'org.apache.httpcomponents:httpcore:jar' into model
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' ('108 : 16,
org.springframework.cloud:spring-cloud-consul-dependencies:1.0.0.M6
/Users/snicoll/.m2/repository/org/springframework/cloud/spring-cloud-consul-dependencies/1.0.0.M6/spring-cloud-consul-dependencies-1.0.0.M6.pom',
'1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
'1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
'1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
'1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom',
'1082 : 16, org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom').
To resolve this conflict, either declare the dependency directly in model
'[inherited]:spring-cloud-dependencies:pom:Brixton.M5' to override what gets
imported or rearrange the c
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158998#comment-15158998
]
Andy Wilkinson commented on MNG-5971:
-
AFAIK, the warnings would not appear if the dependency management had been
declared directly so I'm surprised that they appear if that dependency
management has come via the import of a bom. In their current form, I think the
warnings are a hinderance rather than a help as they actively discourage people
from separating their dependency management out into a reusable bom.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158980#comment-15158980
]
Stephane Nicoll commented on MNG-5971:
--
I will update and re-test but just to answer your question, yes we do rely on
the order of declaration. That's the only way that I know of to manage a
conflict. If several BOMs are working on a set of common dependencies you have
to tell which one wins and ordering the boms (first win strategy) is something
we do for _a very long time_
Practically speaking it also makes sense: you can't possibly ask 4 different
projects to not have _any_ conflicting library at all.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158962#comment-15158962
]
Christian Schulte commented on MNG-5971:
Thanks for testing. That's the conflicts I am referring to. Looking at
{{spring-cloud-dependencies-Brixton.M5.pom}} I noticed this comment
{code}
{code}
You really rely on the order of {{}} elements in the dependency
management intentionally and on that reversed order above overrides below? Can
you grab a recent 3.4.0-SNAPSHOT please to see if the updated warning messages
make it clear what is going on? Currently these warnings are intentional. I am
not sure it is/was a good idea to make things rely on the order of XML
elements. That behaviour can be restored and those warnings can be suppressed.
Do you really think that is a good idea? Having Maven resolve those conflicts
automatically would be cool. If that is only possible based on the order of XML
elements I think forcing users to resolve those conflicts manually based on
real coordinates is a better way to go. That isn't set in stone yet.
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158944#comment-15158944
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1243 (See
[https://builds.apache.org/job/maven-3.x/1243/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev f08e9558df564319efe91839d03c1be03b6833f8)
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158907#comment-15158907
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1242 (See
[https://builds.apache.org/job/maven-3.x/1242/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 8b751f6a8ac4d11d6b9932f0f8b7de795c0296d3)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
> Attachments: bom-cloud.zip
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15158868#comment-15158868
]
Stephane Nicoll commented on MNG-5971:
--
{noformat}
Apache Maven 3.4.0-SNAPSHOT (24e792188260ffd41278555c9452c2a91e2acb3d;
2016-02-22T03:48:56+01:00)
Maven home: /Users/snicoll/tools/maven
Java version: 1.8.0_60, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "Mac OS X", version: "10.11.3", arch: "x86_64", family: "Unix"
{noformat}
Is the following warnings a direct effect of this change?
{noformat}
➜ mvn dependency:list
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.example:demo:jar:0.0.1-SNAPSHOT
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.springframework.integration:spring-integration-http:jar ->
duplicate declaration of version 4.2.4.RELEASE @
org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1803, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1071, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1071, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1071, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1071, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpclient:jar -> version 4.5 vs
4.5.1 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1071, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpcore:jar -> version 4.4.1 vs
4.4.4 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1082, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpcore:jar -> version 4.4.1 vs
4.4.4 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1082, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpcore:jar -> version 4.4.1 vs
4.4.4 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
line 1082, column 16
[WARNING]
'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)'
must be unique: org.apache.httpcomponents:httpcore:jar -> version 4.4.1 vs
4.4.4 @ org.springframework.boot:spring-boot-dependencies:1.3.2.RELEASE,
/Users/snicoll/.m2/repository/org/springframework/boot/spring-boot-dependencies/1.3.2.RELEASE/spring-boot-dependencies-1.3.2.RELEASE.pom,
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157956#comment-15157956
]
Hudson commented on MNG-5971:
-
ABORTED: Integrated in maven-3.x #1238 (See
[https://builds.apache.org/job/maven-3.x/1238/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev d8b66aebfb9166b2b20f93f3078460b0a3913439)
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157525#comment-15157525
]
Hudson commented on MNG-5971:
-
ABORTED: Integrated in maven-3.x #1235 (See
[https://builds.apache.org/job/maven-3.x/1235/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 508e16e23d66de09893d1eb52dff6a1c5ca019b3)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelProblemCollector.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15157107#comment-15157107
]
Hudson commented on MNG-5971:
-
FAILURE: Integrated in maven-3.x #1234 (See
[https://builds.apache.org/job/maven-3.x/1234/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 024a705d4e166cb35d3db7e70feda4522eddeb2f)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156694#comment-15156694
]
Stephane Nicoll commented on MNG-5971:
--
Christian, the sample project works now indeed, awesome! I've installed the
snapshot to use it for the next couple days. I also want to re-test everything
on the project that made me create this issue in the first place. I'll keep you
posted. Thanks!
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156409#comment-15156409
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1233 (See
[https://builds.apache.org/job/maven-3.x/1233/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 24e792188260ffd41278555c9452c2a91e2acb3d)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuildingResult.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelBuildingResult.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
> Fix For: 3.4.0
>
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15155611#comment-15155611
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1232 (See
[https://builds.apache.org/job/maven-3.x/1232/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 8c3a2b717366b32877b9905b70101dd4f6e534e2)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> Imported dependencies should be available to inheritance processing
> ---
>
> Key: MNG-5971
> URL: https://issues.apache.org/jira/browse/MNG-5971
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.3.3
>Reporter: Stephane Nicoll
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15155041#comment-15155041
]
Hudson commented on MNG-5971:
-
FAILURE: Integrated in maven-3.x #1230 (See
[https://builds.apache.org/job/maven-3.x/1230/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 45327208f0fee9d1e0acc168ec072b29b698)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> 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
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154966#comment-15154966
]
Christian Schulte commented on MNG-5971:
@[~snicoll]: Your example project on Github is working as expected using a
recent 3.4.0-SNAPSHOT. Can you please double check?
> 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
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154946#comment-15154946
]
Christian Schulte commented on MNG-5971:
Please let me know if this issue can be closed so that I can write unit tests
and integration tests for the fixed {{import}} scope.
> 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
>Assignee: Christian Schulte
>Priority: Trivial
> Labels: close-pending
>
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154942#comment-15154942
]
Christian Schulte commented on MNG-5971:
I am copying the comment of the last commit here.
{code}
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.
{code}
So a recent
[3.4.0-SNAPSHOT|https://builds.apache.org/view/All/job/maven-3.3-release-status-build/]
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: https://issues.apache.org/jira/browse/MNG-5971
> 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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154864#comment-15154864
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1229 (See
[https://builds.apache.org/job/maven-3.x/1229/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 2313861dfde37b02e6aa8d5d701c8e8bb5a288ea)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelCacheTag.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilderFactory.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DependenciesImporter.java
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependenciesImporter.java
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
> 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
>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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154863#comment-15154863
]
Christian Schulte commented on MNG-5971:
@[~snicoll]: The way the override logic got implemented isn't incorrect. What
is incorrect is that there is no way to override things in child projects. See
the updated description of this issue. That's fixed now. Just execute {{mvn
validate}} with a recent 3.4.0-SNAPSHOT on the following pom. You need to put
the conflicting dependencies coming from multiple imports into the pom (nearer)
to resolve the conflicts. Maven did not warn about this and silently dropped
conflicting dependencies. It shouldn't have done that.
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
localhost
MNG-5971
1-SNAPSHOT
pom
org.springframework.boot
spring-boot-starter-parent
1.3.2.RELEASE
org.springframework
spring-framework-bom
4.2.4.RELEASE
pom
import
org.springframework.cloud
spring-cloud-config
1.0.3.RELEASE
pom
import
{code}
> 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
>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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153984#comment-15153984
]
Stephane Nicoll commented on MNG-5971:
--
I appreciate the work Christian has done but I am -1 on the new scope as well
and I really think the current one is broken. There is no way in my opinion
that you should force a version in the parent. Any child pom can override
whatever they want and it always worked that way in Maven-land. I really don't
get why BOM should behave differently.
What I am after is consistency: if I can override the version of
{{com.foo:bar}} in a child, I should be able to do exactly the same if said
version is provided by a BOM.
> 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
>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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153978#comment-15153978
]
Robert Scholte commented on MNG-5971:
-
Introducing a new scope in modelVersion 4.0.0 is a recipe for disaster. If this
scope ends up in a dependency or parent, you cannot force a specific Maven
version anymore. Any new feature on the current pom must be ported back to a
structure that is supported to all tools using the pom.
{quote}
This very issue is about the fact that adding the dependency directly works,
adding a bom that defines said dependency doesn't. IMO this is inconsistent
considering how we're using BOM (= share a dependency management section).
{quote}
Yes, this is what I would expect as well.
I've read the complete thread and I'm missing a couple of fundamental
statements: as a writer of a parent I must be able to decide if my proposed
versions are final or are just defaults. One of the purposes of
dependencyManagement was to set versions on a higher level and ignore the
version of dependencies on a lower level. In this case dependencyManagement
should work as a safetynet.
So we want to use a BOM to specify default which doesn't work, but as direct
dependency it does. This seems a valid usecase to solve with the
flatten-maven-plugin. We can use the different behavior of imported
dependencies and direct dependencies and go from imported to direct with the
flatten-maven-plugin.
Slowly there are coming more and more usecases which require the build-pom to
be a bit different compared to the distribution-pom. That's something we need
to work on.
In conclusion: -1 for this new scope!
> 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
>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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153544#comment-15153544
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1227 (See
[https://builds.apache.org/job/maven-3.x/1227/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev 354765dd0237e3ab9058f40c9f52c858e4e295bc)
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependenciesImporter.java
> 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
>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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153423#comment-15153423
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1226 (See
[https://builds.apache.org/job/maven-3.x/1226/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev b30be5d6844693910a4861a644e4062021002d1f)
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> 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
>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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153425#comment-15153425
]
Christian Schulte commented on MNG-5971:
The latest commit adds support for property inheritance and interpolation for
{{include}} scope dependencies. If you guys have a lot of projects using
{{import}} scope, please test them using the latest [Maven
3.4.0-SNAPSHOT|https://builds.apache.org/view/All/job/maven-3.3-release-status-build/]
so we can sort out any issues immediately.
> 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
>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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152938#comment-15152938
]
Christian Schulte commented on MNG-5971:
>From an implementation point of view the difference between {{import}} and
>{{include}} currently really is just a method call performed earlier during
>model building. If everyone agrees to the {{include}} scope being a bug fix of
>the {{import}} scope, then changing the behaviour of the {{import}} scope and
>not introducing a new {{include}} scope would be an option. Chances are great
>people using the {{import}} scope will need to correct theire poms.
> 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
>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:
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
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}
${groupId.property}
${artifactId.property}
${version.property}
include
pom
{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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152382#comment-15152382
]
Andy Wilkinson commented on MNG-5971:
-
> For the include scope it will not be possible to use anything requiring
> inheritance processing. Properties would be available only after inheritance
> processing has been performed.
Is that due to a technical restriction or a design choice that's been made? If
I can use a property when defining a managed dependency directly, why can't I
also use a property when I'm using the new {{include}} scope? Put another way,
once property interpolation is available can't the model be processed such that
any {{include}}-scoped dependency is replaced with the content of the bom that
it references?
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152381#comment-15152381
]
Arnaud HERITIER commented on MNG-5971:
--
I agree that the import scope which add depMgt entries which cannot be
redefined was always a nightmare especially nowdays where BOMs are often used
and thus you can override a part of the depMgt with a BOM if the entries were
already defined in another one.
Changing the behavior is difficult, but I'm not sure if it isn't better than an
new scope which will be difficult to explain: import vs include
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152347#comment-15152347
]
Christian Schulte commented on MNG-5971:
If Maven would support multiple inheritance
{code}
...
{code}
none of these features would be needed, right?
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152334#comment-15152334
]
Christian Schulte commented on MNG-5971:
You can grab a recent 3.4.0-SNAPSHOT from the [Jenkins
job|https://builds.apache.org/view/All/job/maven-3.3-release-status-build/] for
testing. Just change {{import}} to {{include}} to see how that goes. Please
report back any issues you are encountering. It's still lacking any unit
testing and I haven't written integration tests yet. Watch out for the SNAPSHOT
to contain this commit:
[af2c42c2c16b6d6f15867646fd82b224359a5910|https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=af2c42c2c16b6d6f15867646fd82b224359a5910]
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152329#comment-15152329
]
Hudson commented on MNG-5971:
-
SUCCESS: Integrated in maven-3.x #1222 (See
[https://builds.apache.org/job/maven-3.x/1222/])
[MNG-5971] Imported dependencies should be available to inheritance (schulte:
rev af2c42c2c16b6d6f15867646fd82b224359a5910)
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependenciesImporter.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/ModelCacheTag.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilderFactory.java
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DependenciesImporter.java
*
maven-model-builder/src/main/java/org/apache/maven/model/composition/DefaultDependencyManagementImporter.java
*
maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152324#comment-15152324
]
Christian Schulte commented on MNG-5971:
For the {{include}} scope it will not be possible to use anything requiring
inheritance processing. Properties would be available only after inheritance
processing has been performed. The {{import}} scope is processed after
inheritance processing and interpolation. So there the complete model features
are available.
> 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)
[jira] [Commented] (MNG-5971) Imported dependencies should be available to inheritance processing
[
https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152297#comment-15152297
]
Andy Wilkinson commented on MNG-5971:
-
{quote}
Since that scope would be processed very early (before inheritance and
interpolation), you cannot use any features like property expansion.
{quote}
Given that I can do this:
{noformat}
com.example.foo
alpha
${foo.version}
com.example.foo
bravo
${foo.version}
{noformat}
I'd really like to be able to move that dependency management out into a
reusable bom and do this:
{noformat}
com.example.foo
foo-bom
${foo.version}
include
pom
{noformat}
If the accepted goal for {{include}} is to provide a shorthand for declaring
the managed dependencies directly, I'd expect that the same rules for the use
of properties would apply. Is that not possible?
> 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)
