anchor.diff:            - Provides usage 'api'
   ----
   
  -As can be seen, _all_ candidate variants are displayed, with their attributes.
  -These are then grouped into two sections:
  +All _compatible_ candidate variants are displayed with their attributes.
   
   * 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.
  +Similar to the ambiguous variant error, the goal is to understand which variant should be selected. In some cases, there may not be any compatible variants from the producer (e.g., trying to run on Java 8 with a library built for Java 11). 
   
   [[sec:variant-visual]]
   == Visualizing variant information
  
positive.code: - `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_
  
  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.
  
  [NOTE]
  .A note about 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.
  ====
  
  [[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
  
  [[sub:variant-ambiguity]]
  === Dealing with ambiguous variant selection errors
  
  An ambiguous variant selection looks somewhat like the following:
  
  [listing]
  ----
  
negative.code: From this you can see the two main configurations used to resolve dependencies, `compileClasspath` and `runtimeClasspath`, as well as their corresponding test configurations.
  
  [[sec:mapping-maven-ivy-to-variants]]
  == Mapping from Maven/Ivy to Gradle variants
  
  Neither Maven nor Ivy have the concept of _variants_, which are only natively supported by Gradle Module Metadata.
  Gradle can still work with Maven and Ivy by using different variant derivation strategies.
  