I would like to be able to write a BOM and tell Maven that for some
dependencies, I am aware of a conflict in the dependency management, but the
conflict arises in a library I don't control, and I know with high
confidence that my users either a) don't care, or b) would be happy with my
recommendation. Unfortunately I don't think there is a sensible way to make
that recommendation.
Here's the concrete actual problem. Spring Cloud has a "release train" which
consists of a "BOM of BOMs"[1], aggregating a bunch of related projects
together by importing their BOMs and providing users with a useful single
point of contact for all the dependencies. It has provide to be a very
popular and successful feature (same with Spring Boot[2]). The problem is
that one of the imported BOMs (Spring Cloud AWS[3]) itself imports a third
party BOM from AWS[4], which itself manages the version of Wiremock[5] (via
its parent[6]). Wiremock is not even used in Spring Cloud AWS, but it
spreads the dependency management to all downstream projects that use its
BOM. Now Wiremock is actually something we care about elsewhere in Spring
Cloud: it is a compile time dependency of Spring Cloud Contract[7] and
naturally we need a different version there.
The visible symptom of this problem is that for any user project that uses
the Spring Cloud BOM, they see a warning in the build logs about a version
conflict for Wiremock. With Maven 3.4 it looks like this currently:
[WARNING] Dependency 'com.github.tomakehurst:wiremock:jar' has conflicting
dependency management in model
'org.springframework.cloud:spring-cloud-dependencies:pom:Camden.SR1'
('org.springframework.cloud:spring-cloud-contract-dependencies:1.0.1.RELEASE',
'com.amazonaws:aws-java-sdk-pom:1.11.18'). To resolve the conflicts, either
declare the dependency management for dependency
'com.github.tomakehurst:wiremock:jar' directly in the dependency management
of model
'org.springframework.cloud:spring-cloud-dependencies:pom:Camden.SR1' to
override what gets imported or - as of model version 4.1.0 - rearrange the
causing imports in the inheritance hierarchy to apply standard override
logic based on artifact coordinates. Without resolving the conflicts, your
build relies on indeterministic behaviour. @
org.springframework.cloud:spring-cloud-dependencies:Camden.SR1
This is independent of whether they intend to use AWS, Contract or Wiremock.
Of course it is true that there is a conflict, but I happen to know that if
they are using any Wiremock features that I provided they will get the
correct version. I doubt very much if the AWS SDK team care a fig. One way I
know to "fix" this warning is to explicitly add dependency management to the
user project for Wiremock, even though the user has no intention of using
it. The same would apply for virtually any unused, but managed dependency.
The suggestion in the log there is to manage it explicitly in
spring-cloud-dependencies, but then I have to synchronize the version
between there are Spring Cloud Contract, which is ugly. I could do that, but
then logically I'd have to do it for all the unused dependencies, which in
principle I have no control over and possibly also no opinion about. Also
I'd have to co-ordinate the version for those dependencies between two
projects that don't depend on each other and one of which doesn't even care
about the dependency or its version. This would be tiresome.
You can see an attempt to exclude Wiremock from the Spring Cloud AWS BOM[8].
But this doesn't do anything. As far as I know <exclusions/> in a BOM import
have no effect, so the semantics are undefined. Maybe we could define them
in such as way that I could tell Maven I know what I'm doing? I.e. I want to
manage the dependency on Wiremock at this layer (above the imported BOMs)
and signal my intention by adding an exclusion.
Of course, I remain open to suggestion if anyone has any better ideas.
[1]
https://github.com/spring-cloud/spring-cloud-release/blob/master/spring-cloud-dependencies/pom.xml
[2]
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-dependencies/pom.xml
[3]
https://github.com/spring-cloud/spring-cloud-aws/blob/master/spring-cloud-aws-dependencies/pom.xml
[4] http://repo1.maven.org/maven2/com/amazonaws/aws-java-sdk-bom
[5] http://repo1.maven.org/maven2/com/github/tomakehurst/wiremock
[6] http://repo1.maven.org/maven2/com/amazonaws/aws-java-sdk-pom
[7]
https://github.com/spring-cloud/spring-cloud-contract/blob/master/spring-cloud-contract-dependencies/pom.xml
[8]
https://github.com/spring-cloud/spring-cloud-aws/blob/1.1.x/spring-cloud-aws-dependencies/pom.xml#L45
--
View this message in context:
http://maven.40175.n5.nabble.com/Layered-BOMs-and-overriding-dependency-management-tp5884866.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
