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: 
  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_ system.
  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 resolution result.
  
  .The Maven component model
  image::component-model-maven.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 the 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:
  
  .The Gradle component model
  image::component-model-gradle.png[]
  
  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.
  
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.
  