maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Nicoll (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MNG-5971) Dependency management in a child project cannot override a version using a BOM
Date Thu, 18 Feb 2016 08:08:18 GMT

    [ https://issues.apache.org/jira/browse/MNG-5971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15151909#comment-15151909
] 

Stephane Nicoll commented on MNG-5971:
--------------------------------------

Please stop looking at two poms in Spring Boot, the issue is more complicated than that and
I've attached a sample project in my original description. Can we stop discussing technical
and discuss feature please? :)

So yes, I would like that a BOM defined at a given level is included in the dependency management
of said level, overriding what is provided by the parent if necessary. And that whole thing
should become the dependency management of that level, that can be also overridden further
down the road if necessary. Long story short: I want bom imports to behave _exactly as_ if
I added each dependency contained in the bom directly in the project.

Your example is correct.

No back on the _feature_. BOM is an effective way of sharing dependencies: instead of having
to copy 10 {{<dependency>}} with their respective versions, I put them all in a bom
and I import that bom with scope {{import}}. This is a very effective way of sharing a dependency
management. All I am asking here is that it behaves  consistently in Maven. 

You already said that the current behaviour is on purpose (and other users don't want the
bom to override dependencies) which means the bom would be some kind of "default if not exist"
thing. I honestly don't understand the use case the way we (and others in the community) use
the bom.

On my own personal opinion, the use case I am describing is _much more logical_ than the current
behaviour: when you import a BOM in a project, it would be as if you had copy/pasted all the
{{dependencyManagement}} section of that BOM  in the project. So I am seeing the BOM as a
shortcut. Does that make sense?



> Dependency management in a child project cannot override a version using a BOM
> ------------------------------------------------------------------------------
>
>                 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
>              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)

Mime
View raw message