UnsolvableVersionConflictException when using io.opencensus/opencensus-exporter-trace-stackdriver

[angusiguess]

Using lein tools deps, lein :tree (and uberjar, run, and likely anything else that requires classpath resolution) don't run.

A project that produces this error can be found here

Steps to reproduce:

Using the 0.4.5 release of lein-tools-deps and the latest version of the clojure cli:

• Run deps: clj -Stree
• Run lein: lein deps :tree, resulting in this error:

https://maven.apache.org/resolver/maven-resolver-api/apidocs/org/eclipse/aether/collection/UnsolvableVersionConflictException.html

[:message Could not resolve version conflict among
	  [io.grpc:grpc-protobuf-lite:jar:1.21.0 -> io.grpc:grpc-api:jar:1.21.0,
	   io.grpc:grpc-alts:jar:1.21.0 -> io.grpc:grpc-core:jar:[1.21.0,1.21.0] -> io.grpc:grpc-api:jar:[1.21.0,1.21.0],
	   io.grpc:grpc-stub:jar:1.25.0 -> io.grpc:grpc-api:jar:1.25.0,
	   io.grpc:grpc-protobuf:jar:1.21.0 -> io.grpc:grpc-api:jar:1.21.0,
	   io.grpc:grpc-api:jar:1.25.0, io.grpc:grpc-auth:jar:1.25.0 -> io.grpc:grpc-api:jar:[1.25.0,1.25.0]]]

Note: lein doesn't handle this exception very clearly because it doesn't implement getResult, I've had to patch leiningen.core.classpath/print-failures to look like this:

(defn- print-failures [e]
  (doseq [result (.getArtifactResults (.getResult e))
          :when (not (.isResolved result))
          exception (.getExceptions result)]
    (warn (.getMessage exception)))
  (doseq [ex (.getCollectExceptions (.getResult e))
          ex2 (.getExceptions (.getResult ex))]
    (warn (.getMessage ex2))))

clj -Stree shows this (arrows are mine):

io.opencensus/opencensus-exporter-trace-stackdriver 0.25.0
  io.grpc/grpc-stub 1.25.0 <---
  com.google.cloud/google-cloud-trace 0.100.0-beta
    com.google.api.grpc/proto-google-cloud-trace-v2 0.65.0
    com.google.cloud/google-cloud-core-grpc 1.82.0
      com.google.api/gax-grpc 1.47.1
        io.grpc/grpc-alts 1.21.0 <---
          org.apache.commons/commons-lang3 3.5
          io.grpc/grpc-grpclb 1.21.0
        io.grpc/grpc-protobuf 1.21.0 <---
          io.grpc/grpc-protobuf-lite 1.21.0 <---
      com.google.cloud/google-cloud-core 1.82.0
        com.google.api.grpc/proto-google-iam-v1 0.12.0
        com.google.protobuf/protobuf-java-util 3.7.1
        com.google.code.findbugs/jsr305 3.0.2
        com.google.api/gax 1.47.1
          org.threeten/threetenbp 1.3.3
    com.google.api.grpc/proto-google-cloud-trace-v1 0.65.0
      com.google.api/api-common 1.8.1
      com.google.api.grpc/proto-google-common-protos 1.16.0
      com.google.protobuf/protobuf-java 3.7.1
io.grpc/grpc-core 1.25.0
    io.perfmark/perfmark-api 0.19.0
    com.google.android/annotations 4.1.1.4
    io.opencensus/opencensus-contrib-grpc-metrics 0.21.0
  io.opencensus/opencensus-contrib-resource-util 0.25.0
  io.grpc/grpc-netty-shaded 1.25.0
  io.grpc/grpc-auth 1.25.0
    com.google.auth/google-auth-library-credentials 0.17.1
    io.grpc/grpc-api 1.25.0 <---
      com.google.errorprone/error_prone_annotations 2.3.3
      com.google.guava/guava 28.1-android
        org.codehaus.mojo/animal-sniffer-annotations 1.17
        com.google.guava/listenablefuture 9999.0-empty-to-avoid-conflict-with-guava
        org.checkerframework/checker-compat-qual 2.5.5
        com.google.guava/failureaccess 1.0.1
        com.google.j2objc/j2objc-annotations 1.3

All of the dependencies that generate conflicts are transitive dependencies inside this one.

Is this a bug with lein-tools-deps or should I expect this behaviour with some dependencies? Are there any workarounds?

Thanks for your help!

[RickMoynihan]

Not sure, does the error also occur when using the clojure command line tooling?

[RickMoynihan]

Ok I can confirm I can reproduce with your example. And that it doesn't happen in tools.deps.

My best guess is that it's most likely due to #91. Based on the -Stree output you pasted above the dependencies in that library seem pretty weird in that there appears to be a circular dependency on one of the transitive dependencies (i.e. it depends on itself), but I've not looked into it.

My suspicion is that this by flattening the tree we prevent resolution of this that causes a conflict. So I'd hope fixing #91 fixes this.