anchor.diff:  - `org.gradle.jvm.version` that describes the _minimal version_ of Java this variant targets
   - `org.gradle.jvm.environment` that describes the type of JVM this variant targets
   
  -Let's consider an example where the consumer wants to compile against a library with both JDK 8 and JDK 11.
  -
  -First, the consumer needs to explain which version of the JDK it needs.
  -
  -In addition to other attributes, the consumer wants to resolve a variant that matches:
  -- `org.gradle.jvm.version=8` which means  _at least running on JDK 8_
  +Let's consider an example where the consumer wants to run tests with a library on Java 8 and the producer supports two different Java versions (Java 8 and Java 11).
  +
  +First, the consumer needs to explain which version of the Java it needs.
  +
  +The consumer wants to resolve a variant that:
  +- can be used at runtime (has `org.gradle.usage=JAVA_RUNTIME`)
  +- can be run on _at least_ Java 8 (`org.gradle.jvm.version=8`)
   
   Second, the producer needs to expose the different variants of the component.
   
  -The producer component exposes 2 variants: 
  -- its API (named `apiElements`) with attribute `org.gradle.usage=JAVA_API`
  -- its runtime (named `runtimeElements`) with attribute `org.gradle.usage=JAVA_RUNTIME`
  -
  -Finally, Gradle selects the appropriate variant by looking at the variant attributes:
  -- the consumer wants a variant with attributes `org.gradle.usage=JAVA_API`
  -- the producer has a matching variant (`apiElements`)
  -- the producer has a non-matching variant (`runtimeElements`)
  -
  -Gradle provides the artifacts and dependencies from the `apiElements` variant to the consumer.
  -
  -
  -With Gradle, this is elegantly solved by having the producer declare 2 variants:
  -
  -- one with 
  -- one with `org.gradle.jvm.version=9`, for consumers starting from JDK 9
  -
  -Note that the artifacts for both variants will be different, but their dependencies _may_ be different too.
  -Typically, the JDK 8 variant may need a "backport" library of JDK 9+ to work, that only consumers running on JDK 8 should get.
  -
  -On the consumer side, the _resolvable configuration_ will set all four attributes above, and, depending on the runtime, will set its `org.gradle.jvm.version` to 8 or more.
  +Like in the simple example, there is both a API (compilation) and runtime variant. These exist for both the Java 8 and Java 11 version of the component.
  +- its API for Java 8 consumers (named `apiJava8Elements`) with attribute `org.gradle.usage=JAVA_API` and `org.gradle.jvm.version=8`
  +- its runtime for Java 8 consumers (named `runtime8Elements`) with attribute `org.gradle.usage=JAVA_RUNTIME` and `org.gradle.jvm.version=8`
  +- its API for Java 11 consumers (named `apiJava11Elements`) with attribute `org.gradle.usage=JAVA_API` and `org.gradle.jvm.version=11`
  +- its runtime for Java 11 consumers (named `runtime11Elements`) with attribute `org.gradle.usage=JAVA_RUNTIME` and `org.gradle.jvm.version=11`
  +
  +Finally, Gradle selects the best matching variant by looking at all of the attributes:
  +- the consumer wants a variant with compatible attributes to `org.gradle.usage=JAVA_RUNTIME` and `org.gradle.jvm.version=8`
  +- the variants `runtime8Elements` and `runtime11Elements` have `org.gradle.usage=JAVA_RUNTIME`
  +- the variants `apiJava8Elements` and `apiJava11Elements` are incompatible
  +- the variant `runtime8Elements` is compatible because it can run on Java 8
  +- the variant `runtime11Elements` is incompatible because it cannot run on Java 8
  +
  +Gradle provides the artifacts and dependencies from the `runtime8Elements` variant to the consumer.
   
   [NOTE]
  -.A note about compatibility of variants
  +.Compatibility of variants
   ====
   What if the consumer sets `org.gradle.jvm.version` to 7?
   
  -Then resolution would _fail_ with an error message explaining that there's no matching variant of the producer.
  -This is because Gradle recognizes that the consumer wants a Java 7 compatible library, but the _minimal_ version of Java available on the producer is 8.
  -If, on the other hand, the consumer needs _11_, then Gradle knows both the _8_ and _9_ variant would work, but it will select _9_ because it's the highest compatible version.
  +Dependency resolution would _fail_ with an error message explaining that there's no suitable variant.
  +Gradle recognizes that the consumer wants a Java 7 compatible library and the _minimal_ version of Java available on the producer is 8.
  +
  +If the consumer requested `org.gradle.jvm.version=15`, then Gradle knows either the Java 8 or Java 11 variants could work. Gradle select the highest compatible Java version (11).
   ====
   
   [[sec:variant-select-errors]]
   == Variant selection errors
   
  -In the process of identifying the right variant of a component, two situations will result in a resolution error:
  -
  -* More than one variant from the producer match the consumer attributes, there is variant ambiguity
  -* No variant from the producer match the consumer attributes
  +When selecting the most compatible variant of a component, resolution may fail:
  +* when more than one variant from the producer matches the consumer attributes (ambiguity error)
  +* when no variants from the producer match the consumer attributes (incompatibility error)
   
   [[sub:variant-ambiguity]]
  -=== Dealing with ambiguous variant selection errors
  -
  -An ambiguous variant selection looks somewhat like the following:
  +=== Dealing with ambiguity errors
  +
  +An ambiguous variant selection looks like the following:
   
   [listing]
   ----
  
positive.code:           - Provides usage 'api'
  ----
  
  As can be seen, _all_ candidate variants are displayed, with their attributes.
  These are then grouped into two sections:
  
  * Incompatible attributes are presented first, as they usually are the key in understanding why a variant could not be selected.
  * Other attributes are presented second, this includes _required_ and _compatible_ ones as well as all extra _producer_ attributes that are not requested by the consumer.
  
  Similarly with the ambiguous variant error, the goal is then to understand which variant is to be selected and see which attribute or capability can be tweaked on the consumer for this to happen.
  
  [[sec:variant-visual]]
  == Visualizing variant information
  
negative.code: 
  In other dependency management engines, like Apache Maven™, dependencies and artifacts are bound to a component that is published at a particular GAV (group-artifact-version) coordinates.
  The set of dependencies for this component are always the same, regardless of which artifact may be used from the component.
  
  If the component does have multiple artifacts, each one is identified by a cumbersome _classifier_.
  There are no common semantics associated with classifiers and that makes it difficult to guarantee a globally consistent dependency graph.
  This means that nothing prevents multiple artifacts for a single component (e.g., `jdk7` and `jdk8` classifiers) from appearing in a classpath and causing hard to diagnose problems.
  
  == Maven component model
  
  .The Maven component model
  image::component-model-maven.png[]
  
  == Gradle component model
  
  .The Gradle component model
  image::component-model-gradle.png[]
  
  Gradle's dependency management engine is _variant aware_.
  
  In addition to a component, Gradle has the concept of _variants_ of a component.
  Variants correspond to the different ways a component can be used, such as for Java compilation or native linking or documentation.
  Artifacts are attached to a _variant_ and each variant can have a different set of dependencies:
  
  How does Gradle know which variant to choose when there's more than one?
  Variants are matched by use of <<variant_attributes.adoc#variant_attributes,attributes>>, which provide semantics to the variants and help the engine to produce a _consistent_ resolution result.
  