Skip to content

Latest commit

 

History

History

guava-jdk-variants

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 

NOTE:

This use cases also works with a real fork of Guava that publishes Gradle Module Metadata. Execute the following in the parent directory of this repository:

git clone git@github.com:jjohannes/guava.git
cd guava
git checkout gradle-module-metadata
util/set_version.sh 28.1
mvn -DskipTests=true install
mvn -DskipTests=true install -f android

What's the use case?

Guava publishes two variants: one for JDK6+ and one for JDK8+. In an attempt to avoid both variants in a dependency graph, the "variant name" is encoded in the version. Each Guava version is published twice: 28.1-android (JDK6) and 28.1-jre (JDK8)

How is it solved?

In Gradle Module Metadata, arbitrary many variants can be published explicitly. Each variant can have individual dependencies and artifacts. Variant attributes are used to distinguish variants and can also be used to express that variants are mutually exclusive. Gradle supports a set of default attributes, including org.gradle.jvm.version. Utilising that, Guava can now publish the following variants:

  • apiElements: compile classpath dependencies, org.gradle.jvm.version = 8, artifact = guava-28.1-jre.jar
  • runtimeElements: runtime classpath dependencies, org.gradle.jvm.version = 8, artifact = guava-28.1-jre.jar
  • jdk6ApiElements: compile classpath dependencies, org.gradle.jvm.version = 6, artifact = guava-28.1-android.jar
  • jdk6RuntimeElements: runtime classpath dependencies, org.gradle.jvm.version = 6, artifact = guava-28.1-android.jar

A build depending on Guava, will now automatically choose one, and only one, compatibly variant based on the java.targetCompatibility setting.