1

If I add the com.google.truth.extensions:truth-proto-extension:1.1 jar to my bazel workspace, it seems to totally nuke the classes from com.google.guava:guava:28.2-jre, resulting in errors like

import static com.google.common.collect.ImmutableMap.toImmutableMap;
^
  symbol:   static toImmutableMap
  location: class ImmutableMap
java/com/google/fhir/protogen/ProtoGenerator.java:316: error: cannot find symbol
            .collect(toImmutableMap(def -> def.getId().getValue(), def -> def));
                     ^
  symbol:   method toImmutableMap((def)->def[...]lue(),(def)->def)
  location: class ProtoGenerator

Your documentation says

One warning: Truth depends on the “Android” version of Guava, a subset of the “JRE” version.
If your project uses the JRE version, be aware that your build system might select the Android version instead.
If so, you may see “missing symbol” errors.
The easiest fix is usually to add a direct dependency on the newest JRE version of Guava.

Does this mean anything other than the maven dep on com.google.guava:guava:28.2-jre? If not, what's the next easiest fix?

Nick
  • 220
  • 1
  • 2
  • 12

1 Answers1

1

The key word here is "newest": You'll need to depend on (as of this writing) 30.1-jre. I have edited the docs to emphasize this.

(You can see the newest version in various locations, including: Maven Central, Maven Central Search, the Guava GitHub page.)

The problem is:

  • Some tools (including Gradle as well as the maven_install rule from Bazel's rules_jvm_external) pick the "newest" version of any given artifact among all versions found in your transitive dependencies.
  • Truth 1.1 depends on version 30.0-android.
  • 30.0-android is considered to be "newer" than 28.2-jre (because 30 is greater than 28).
  • The -android releases lack the Java 8 APIs.

(So you can actually fix this by depending on any -jre version from 30.0-jre up: 30.0-jre is considered "newer" than 30.0-android because of alphabetical order. Fun!)

Unfortunately, the Maven ecosystem doesn't support a good way to offer 2 "flavors" of every release (JRE+Android). (People often suggest the Maven "classifier," but that does not actually solve the problem.)

For the future:

  • Gradle: Gradle is working with us to provide its own solution, but it's not quite ready yet.
  • Maven: Maven is unlikely to provide help. (It doesn't even try to pick the "newest" version, let alone support "flavors.")
  • Bazel: I don't know if rules_jvm_external (which uses Coursier) has any plans to support "flavors."
Chris Povirk
  • 3,738
  • 3
  • 29
  • 47