Am 11/03/16 um 15:57 schrieb Dave Syer:
> 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.
Using current 3.4.0-SNAPSHOT master you can set the model version to
4.1.0 and then you can use excludes in the dependency management import.
Would that solve the issue for you? Could you give that a quick test? I
know we are not going to release model version 4.1.0. It'd like to know
if support for the exclusions element in dependency management imports
need to be provided together with the changes to the import scope.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
