Error in fail: Found duplicate artifact versions (gson, error_prone_annotations, guava) when bumping rules_jvm_external from 6.8 to 6.9

[vorburger]

To test #1181, I'm adding:

git_override(
    module_name = "rules_jvm_external",
    remote = "https://github.com/bazelbuild/rules_jvm_external",
    commit = "7a7d0383e585cbbab5d69dce65b0d90ee84ce3ed",
)

after bazel_dep(name = "rules_jvm_external", version = "6.8") in my MODULE.bazel, but it's causing enola-dev/enola#1831:

Error in fail: Found duplicate artifact versions
    com.google.code.gson:gson has multiple versions 2.13.1, 2.8.9
    com.google.errorprone:error_prone_annotations has multiple versions 2.41.0, 2.5.1
    com.google.guava:guava has multiple versions 33.4.8-jre, 32.0.1-jre
Please remove duplicate artifacts from the artifact list so you do not get unexpected artifact versions

I don't understand where these are coming from, nor how / where to remove them... how can the bump of rules_jvm_external cause this?

Smells like old #934 and #1168 ?

@vinnybod @shs96c

[vorburger]

I'm now seeing this when bumping from 6.8 to 6.9 in enola-dev/enola#1942.

See https://docs.enola.dev/dev/dependencies/#java for my project's dependencies.

I don't understand where these are coming from, nor how / where to remove them... how can the bump of rules_jvm_external cause this?

It probably just got stricter, and now finds (sees) something that was always there?

Looking at What's Changed on https://github.com/bazel-contrib/rules_jvm_external/releases/tag/6.9,

I wonder whether perhaps #1458 by @shs96c could been causing this?

What's confusing is that in my project I have set the versions of those to the latest, so I would expect it to use those.

It would be extremely neat and useful if the resolver/s would print a mvn dependency:tree like tree view of exactly WHERE those conflicting "multiple versions" were found... then it would be easy to add the required exclusions.

Perhaps I can try using another resolver, and try the Maven or Gradle instead of the Coursier resolver?

[vorburger]

Perhaps I can try using another resolver, and try the Maven or Gradle instead of the Coursier resolver?

Adding resolver = "maven", here (for this), and then re-running ./MODULE.update.bash causes a surprising number of version differences, in my project! The docs/dev/dependencies.txt dif (which powers my https://docs.enola.dev/dev/dependencies/#java) is fairly significant. Perhaps it would be best to "pin" those divergences to current versions anyway.. and then see if this still happens.

PS: Adding resolver = "gradle", causes an entirely different problem, but as that's anyway still marked "considered experimental" here, I'll ignore this, and focus only on pursuing switching to resolver = "maven", instead of figuring this out:

Loading: 117 packages loaded
    currently loading: java/dev/enola
ERROR: /home/vorburger/.cache/bazel/_bazel_vorburger/a3cf8df34f0c7a76e9926daaad9ffbf4/external/rules_jvm_external++maven+maven/BUILD:14764:11: in jvm_import rule @@rules_jvm_external++maven+maven//:org_jetbrains_kotlin_kotlin_stdlib_jdk8: cycle in dependency graph:
    //java/dev/enola:api (d8a30c5d758708484abd3f227aebaf82303950516e1059e52d107d5e0333128b)
    //java/dev/enola:api (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
    //java/dev/enola/thing:thing_java (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
    //java/dev/enola/common/protobuf:protobuf (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
    //java/dev/enola/common/yamljson:yamljson (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
    //java/dev/enola/common/io:io (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
    @@rules_jvm_external++maven+maven//:com_squareup_okhttp3_okhttp (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
.-> @@rules_jvm_external++maven+maven//:org_jetbrains_kotlin_kotlin_stdlib_jdk8 (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
|   @@rules_jvm_external++maven+maven//:org_jetbrains_kotlin_kotlin_stdlib_jdk7 (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
|   @@rules_jvm_external++maven+maven//:org_jetbrains_kotlin_kotlin_stdlib (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
`-- @@rules_jvm_external++maven+maven//:org_jetbrains_kotlin_kotlin_stdlib_jdk8 (31bdca656b89f9b5b621900e99de2b2901632c153c94534348cf7b6c2ff91f00)
ERROR: Analysis of target '//java/dev/enola:api' failed; build aborted
INFO: Elapsed time: 4.265s

[vorburger]

Adding resolver = "maven", here (for this), and then re-running ./MODULE.update.bash causes a surprising number of version differences, in my project! The docs/dev/dependencies.txt dif (which powers my https://docs.enola.dev/dev/dependencies/#java) is fairly significant. Perhaps it would be best to "pin" those divergences to current versions anyway.. and then see if this still happens.

enola-dev/enola#1947 did that (clean-up various dependencies) - but unfortunately none of that fixes this.

It would be extremely neat and useful if the resolver/s would print a mvn dependency:tree like tree view of exactly WHERE those conflicting "multiple versions" were found... then it would be easy to add the required exclusions.

@shs96c if there any way to have it do that?

[vinnybod]

There have been some other fixes to the initial exclusion implementation post-6.9 but are not in a release yet. Can you try using a git_override to use the HEAD of master and see if the problems persist? If they do, I can take a deeper look.