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 Wed, 17 Feb 2016 13:48:18 GMT

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

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

"Override what is already there". This is quite a big issue in Spring Boot land today. We
are promoting a "starter-parent" concept where a set of plugins are pre-configured with sensible
defaults and "core" dependencies can be managed via properties (see the {{spring-boot-dependencies}}
and {{spring-boot-starter-parent}}). 

This works fine until we started to integrate other components on top of Spring Boot that
have their own boms and some specific requirements regarding dependencies. Spring Cloud Services
is a typical case that is causing trouble: that project need to override the version of one
dependency provided in the parent and there is no way in Maven to do that. What  we document
is to add the bom and you should be good to go.

Failing is not an option and It looks like we have different concept of what a BOM is. In
my opinion, a BOM is way to share the dependency management of a set of dependencies. As such,
when a BOM is added in a project, it should behave exactly as if all the dependencies that
it contains were added to the project. Since adding the dependency explicitly (rather than
via the import of a bom) works, I guess this was intentional. I honestly don't get why it
should behave differently.

Taking a bit of distance of the actual problem, I think our use case is actually quite nice:
we want to provide _default_ dependencies management and a set of nice defaults for plugins
that are typically used in a Spring Boot application. The only way I know to do that is via
a parent pom. That's what we  did. Now we are stuck if the user wants to override the version
of a dependency because the bom import does not work. I feel that use case is legit. What
would you recommend then?

> 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