[
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)
