anchor.diff:  The rule creates an `apiElements` variant based on the `compile` configuration and a `runtimeElements` variant based on the `default` configuration of each ivy module.
   For each variant, it sets the corresponding <<#sec:variant-aware-matching,Java ecosystem attributes>>.
   Dependencies and artifacts of the variants are taken from the underlying configurations.
  -If not all consumed ivy modules follow this pattern, the rule can be adjusted or only applied to a selected set of modules.
  -
  -For all ivy modules without variants, Gradle falls back to legacy configuration selection (i.e. Gradle does _not_ perform variant aware resolution for these modules).
  -This means either the `default` configuration or the configuration explicitly defined in the dependency to the corresponding module is selected.
  -(Note that explicit configuration selection is only possible from build scripts or ivy metadata, and should be avoided in favor of variant selection.)
  -
  +If not all consumed Ivy modules follow this pattern, the rule can be adjusted or only applied to a selected set of modules.
  +
  +For all Ivy modules without variants, Gradle has a fallback selection method. Gradle does _not_ perform variant aware resolution and instead selects either the `default` configuration or an explicitly named configuration.
  
positive.code: :metadata-file-spec: https://github.com/gradle/gradle/blob/master/subprojects/docs/src/docs/design/gradle-module-metadata-latest-specification.md
  
  [[understanding-variant-selection]]
  = Understanding variant selection
  
  Gradle's dependency management engine is known as _variant aware_.
  In a traditional dependency management engine like Apache Maven™, dependencies are bound to components published at GAV coordinates.
  This means that the set of transitive dependencies for a component is solely determined by the GAV coordinates of this component.
  It doesn't matter what _artifact_ is actually resolved, the set of dependencies is _always the same_.
  In addition, selecting a different artifact for a component (for example, using the `jdk7` artifact) is cumbersome as it requires the use of _classifiers_.
  One issue with this model is that it cannot guarantee global graph consistency because there are no common semantics associated with _classifiers_.
  What this means is that there's nothing which prevents from having both the `jdk7` and `jdk8` versions of a single module on classpath, because the engine has no idea what semantics are associated with the classifier name.
  
  .The Maven component model
  image::component-model-maven.png[]
  
  Gradle, in addition to the concept of a _module_ published at GAV coordinates, introduces the concept of _variants_ of this module.
  Variants correspond to the different "views" of a component that is published at the same GAV coordinates.
  In the Gradle model, artifacts are attached to _variants_, not modules.
  This means, in practice, that different _artifacts_ can have a different set of dependencies:
  
  .The Gradle component model
  image::component-model-gradle.png[]
  
  This intermediate level, which associates artifacts and dependencies to variants instead of directly to the component, allows Gradle to model properly what each artifact is used for.
  
  However, this raises the question about how variants are selected: how does Gradle know which variant to choose when there's more than one?
  In practice, variants are selected thanks to the use of <<variant_attributes.adoc#variant_attributes,attributes>>, which provide semantics to the variants and help the engine in achieving a _consistent resolution result_.
  
  For historical reasons, Gradle differentiates between two kind of components:
  
  - local components, built from sources, for which <<#sec:abm_configuration_attributes, variants are mapped to outgoing configurations>>
  - external components, published on repositories, in which case either the module was published with Gradle Module Metadata and variants are natively supported, or the module is using Ivy/Maven metadata and <<#sec:mapping-maven-ivy-to-variants,variants are derived from metadata>>.
  
  In both cases, Gradle performs _variant aware selection_.
  
  [[sec:abm_configuration_attributes]]
  == Configuration and variant attributes
  
  Local components expose variants as _outgoing configurations_, which are <<declaring_dependencies.adoc#sec:resolvable-consumable-configs,consumable configurations>>.
  When dependency resolution happens, the engine will select one variant of an outgoing component by selecting one of its _consumable configurations_.
  
  [NOTE]
  ====
  There are 2 noticeable exception to this rule:
  
  - whenever a producer does _not_ expose any consumable configuration
  - whenever the consumer _explicitly selects a target configuration_
  
  In this case, _variant aware resolution is bypassed_.
  ====
  
  Attributes are used on both _resolvable configurations_ (also known as a _consumer_) and _consumable configurations_ (on the _producer_).
  Adding attributes to other kinds of configurations simply has no effect, as attributes are not inherited between configurations.
  
  The role of the dependency resolution engine is to find a suitable _variant_ of a _producer_ given the constraints expressed by a _consumer_.
  
  This is where attributes come into play: their role is to perform the selection of the right _variant_ of a component.
  
  [NOTE]
  .Variants vs configurations
  ====
  For external components, the terminology is to use the word _variants_, not _configurations_. Configurations are a super-set of variants.
  
  This means that an external component provides _variants_, which also have attributes.
  However, sometimes the term _configuration_ may leak into the DSL for historical reasons, or because you use Ivy which also has this concept of _configuration_.
  ====
  
  [[sec:variant-visual]]
  == Visualizing variant information
  
  === The Outgoing Variants Report
  
  Gradle offers a report task called `outgoingVariants` that displays the variants of a project, with their capabilities, attributes and artifacts.
  It is conceptually similar to the `dependencyInsight` <<viewing_debugging_dependencies.adoc#sec:identifying_reason_dependency_selection,reporting task>>.
  
  By default, `outgoingVariants` prints information about all variants.
  It offers the optional parameter `--variant <variantName>` to select a single variant to display.
  It also accepts the `--all` flag to include information about legacy and deprecated configurations.
  
  Here is the output of the `outgoingVariants` task on a freshly generated `java-library` project:
  
  [listing]
  ----
  > Task :outgoingVariants
  --------------------------------------------------
  Variant apiElements
  --------------------------------------------------
  Description = API elements for main.
  
  Capabilities
      - new-java-library:lib:unspecified (default capability)
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-api
  Artifacts
      - build/libs/lib.jar (artifactType = jar)
  
  Secondary Variants (*)
  
      --------------------------------------------------
      Secondary Variant classes
      --------------------------------------------------
          Description = Directories containing compiled class files for main.
  
          Attributes
              - org.gradle.category            = library
              - org.gradle.dependency.bundling = external
              - org.gradle.jvm.version         = 11
              - org.gradle.libraryelements     = classes
              - org.gradle.usage               = java-api
          Artifacts
              - build/classes/java/main (artifactType = java-classes-directory)
  
  --------------------------------------------------
  Variant mainSourceElements (i)
  --------------------------------------------------
  Description = List of source directories contained in the Main SourceSet.
  
  Capabilities
      - new-java-library:lib:unspecified (default capability)
  Attributes
      - org.gradle.category            = verification
      - org.gradle.dependency.bundling = external
      - org.gradle.verificationtype    = main-sources
  Artifacts
      - src/main/java (artifactType = directory)
      - src/main/resources (artifactType = directory)
  
  --------------------------------------------------
  Variant runtimeElements
  --------------------------------------------------
  Description = Elements of runtime for main.
  
  Capabilities
      - new-java-library:lib:unspecified (default capability)
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  Artifacts
      - build/libs/lib.jar (artifactType = jar)
  
  Secondary Variants (*)
  
      --------------------------------------------------
      Secondary Variant classes
      --------------------------------------------------
          Description = Directories containing compiled class files for main.
  
          Attributes
              - org.gradle.category            = library
              - org.gradle.dependency.bundling = external
              - org.gradle.jvm.version         = 11
              - org.gradle.libraryelements     = classes
              - org.gradle.usage               = java-runtime
          Artifacts
              - build/classes/java/main (artifactType = java-classes-directory)
  
      --------------------------------------------------
      Secondary Variant resources
      --------------------------------------------------
          Description = Directories containing the project's assembled resource files for use at runtime.
  
          Attributes
              - org.gradle.category            = library
              - org.gradle.dependency.bundling = external
              - org.gradle.jvm.version         = 11
              - org.gradle.libraryelements     = resources
              - org.gradle.usage               = java-runtime
          Artifacts
              - build/resources/main (artifactType = java-resources-directory)
  
  --------------------------------------------------
  Variant testResultsElementsForTest (i)
  --------------------------------------------------
  Description = Directory containing binary results of running tests for the test Test Suite's test target.
  
  Capabilities
      - new-java-library:lib:unspecified (default capability)
  Attributes
      - org.gradle.category              = verification
      - org.gradle.testsuite.name        = test
      - org.gradle.testsuite.target.name = test
      - org.gradle.testsuite.type        = unit-test
      - org.gradle.verificationtype      = test-results
  Artifacts
      - build/test-results/test/binary (artifactType = directory)
  
  (i) Configuration uses incubating attributes such as Category.VERIFICATION.
  (*) Secondary variants are variants created via the Configuration#getOutgoing(): ConfigurationPublications API which also participate in selection, in addition to the configuration itself.
  ----
  
  From this you can see the two main variants that are exposed by a java library, `apiElements` and `runtimeElements`.
  Notice that the main difference is on the `org.gradle.usage` attribute, with values `java-api` and `java-runtime`.
  As they indicate, this is where the difference is made between what needs to be on the _compile_ classpath of consumers, versus what's needed on the _runtime_ classpath.
  
  It also shows _secondary_ variants, which are exclusive to Gradle projects and not published.
  For example, the secondary variant `classes` from `apiElements` is what allows Gradle to skip the JAR creation when compiling against a <<java_library_plugin.adoc#sec:java_library_classes_usage,`java-library` project>>.
  
  === The Resolvable Configurations Report
  
  Gradle also offers a complimentary report task called `resolvableConfigurations` that displays the _resolvable_ configurations of a project, which are those which can have dependencies added and be resolved.  The report will list their attributes and any configurations that they extend.  It will also list a summary of any attributes which will be affected by <<variant_attributes.adoc#sec:abm_compatibility_rules, Compatibility Rules>> or <<variant_attributes.adoc#sec:abm_disambiguation_rules, Disambiguation Rules>> during resolution.
  
  By default, `resolvableConfigurations` prints information about all purely resolvable configurations.
  These are configurations that are marked resolvable but *not* marked consumable.
  Though some resolvable configurations are also marked consumable, these are legacy configurations that should *not* have dependencies added in build scripts.
  This report offers the optional parameter `--configuration <configurationName>` to select a single configuration to display.
  It also accepts the `--all` flag to include information about legacy and deprecated configurations.
  Finally, it accepts the `--recursive` flag to list in the extended configurations section those configurations which are extended _transitively_ rather than directly.
  
  Here is the output of the `resolvableConfigurations` task on a freshly generated `java-library` project:
  
  [listing]
  ----
  > Task :resolvableConfigurations
  --------------------------------------------------
  Configuration annotationProcessor
  --------------------------------------------------
  Description = Annotation processors and their dependencies for source set 'main'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  
  --------------------------------------------------
  Configuration compileClasspath
  --------------------------------------------------
  Description = Compile classpath for source set 'main'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = classes
      - org.gradle.usage               = java-api
  Extended Configurations
      - compileOnly
      - implementation
  
  --------------------------------------------------
  Configuration runtimeClasspath
  --------------------------------------------------
  Description = Runtime classpath of source set 'main'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  Extended Configurations
      - implementation
      - runtimeOnly
  
  --------------------------------------------------
  Configuration testAnnotationProcessor
  --------------------------------------------------
  Description = Annotation processors and their dependencies for source set 'test'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  
  --------------------------------------------------
  Configuration testCompileClasspath
  --------------------------------------------------
  Description = Compile classpath for source set 'test'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = classes
      - org.gradle.usage               = java-api
  Extended Configurations
      - testCompileOnly
      - testImplementation
  
  --------------------------------------------------
  Configuration testRuntimeClasspath
  --------------------------------------------------
  Description = Runtime classpath of source set 'test'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  Extended Configurations
      - testImplementation
      - testRuntimeOnly
  
  --------------------------------------------------
  Compatibility Rules
  --------------------------------------------------
  Description = The following Attributes have compatibility rules defined.
  
      - org.gradle.dependency.bundling
      - org.gradle.jvm.environment
      - org.gradle.jvm.version
      - org.gradle.libraryelements
      - org.gradle.plugin.api-version
      - org.gradle.usage
  
  --------------------------------------------------
  Disambiguation Rules
  --------------------------------------------------
  Description = The following Attributes have disambiguation rules defined.
  
      - org.gradle.category
      - org.gradle.dependency.bundling
      - org.gradle.jvm.environment
      - org.gradle.jvm.version
      - org.gradle.libraryelements
      - org.gradle.plugin.api-version
      - org.gradle.usage
  ----
  
  From this you can see the two main configurations used to resolve dependencies, `compileClasspath` and `runtimeClasspath`, as well as their corresponding test configurations.
  
  [[sec:variant-aware-matching]]
  == Variant aware matching
  
  Let's take the example of a `lib` library which exposes 2 variants: its API (via a variant named `exposedApi`) and its runtime (via a variant named `exposedRuntime`).
  
  [NOTE]
  .About producer variants
  ====
  The variant _name_ is there mostly for debugging purposes and to get a nicer display in error messages.
  The name, in particular, doesn't participate in the _id_ of a variant: only its attributes do.
  That is to say that to search for a particular variant, one _must_ rely on its attributes, _not_ its name.
  
  There are no restrictions on the number of variants a component can expose.
  Traditionally, a component would expose an API and an implementation, but we may, for example, want to expose the test fixtures of a component too.
  It is also possible to expose _different APIs_ for different consumers (think about different environments, like Linux vs Windows).
  ====
  
  A consumer needs to explain _what_ variant it needs and this is done by setting _attributes_ on the _consumer_.
  
  Attributes consist of a _name_ and a _value_ pair.
  For example, Gradle comes with a standard attribute named `org.gradle.usage` specifically to deal with the concept of selecting the right variant of a component based on the usage of the consumer (compile, runtime ...).
  It is however possible to define an arbitrary number of attributes.
  As a producer, we can express that a consumable configuration represents the API of a component by attaching the `(org.gradle.usage,JAVA_API)` attribute to the variant.
  As a consumer, we can express that we need the API of the dependencies of a resolvable configuration by attaching the `(org.gradle.usage,JAVA_API)` attribute to it.
  Doing this, Gradle has a way to _automatically select the appropriate variant_ by looking at the configuration attributes:
  
  - the consumer wants `org.gradle.usage=JAVA_API`
  - the producer, `lib` exposes 2 different variants. One with `org.gradle.usage=JAVA_API`, the other with `org.gradle.usage=JAVA_RUNTIME`.
  - Gradle chooses the `org.gradle.usage=JAVA_API` variant of the producer because it _matches the consumer attributes_
  
  In other words: attributes are used to perform the selection based on the values of the attributes.
  
  A more elaborate example involves more than one attribute.
  Typically, a Java Library project in Gradle will involve 4 different attributes, found both on the producer and consumer sides:
  
  - `org.gradle.usage`, explaining if the variant is the API of a component, or its implementation
  - `org.gradle.dependency.bundling`, which declares how the dependencies of the component are bundled (for example, if the artifact is a fat jar, then the bundling is `EMBEDDED`)
  - `org.gradle.libraryelements`, which is used to explain what _parts_ of the library the variant contains (classes, resources or everything)
  - `org.gradle.jvm.version`, which is used to explain what _minimal version_ of Java this variant is targeted at
  
  Now imagine that our library comes in two different flavors:
  
  - one for JDK 8
  - one for JDK 9+
  
  This is typically achieved, in Maven, by producing 2 different artifacts, a "main" artifact and a "classified" one.
  However, in Maven a consumer cannot express the fact it needs the _most appropriate_ version of the library based on the runtime.
  
  With Gradle, this is elegantly solved by having the producer declare 2 variants:
  
  - one with `org.gradle.jvm.version=8`, for consumers _at least running on JDK 8_
  - 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.
  
negative.code: 
  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
  
  === Outgoing variants report
  
  The report task `outgoingVariants` shows the list of variants available for selection by consumers of the project. It displays the capabilities, attributes and artifacts for each variant. 
  
  This task is similar to the `dependencyInsight` <<viewing_debugging_dependencies.adoc#sec:identifying_reason_dependency_selection,reporting task>>.
  
  By default, `outgoingVariants` prints information about all variants.
  It offers the optional parameter `--variant <variantName>` to select a single variant to display.
  It also accepts the `--all` flag to include information about legacy and deprecated configurations.
  
  Here is the output of the `outgoingVariants` task on a freshly generated `java-library` project:
  
  [listing]
  ----
  > Task :outgoingVariants
  --------------------------------------------------
  Variant apiElements
  --------------------------------------------------
  Description = API elements for main.
  
  Capabilities
      - new-java-library:lib:unspecified (default capability)
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-api
  Artifacts
      - build/libs/lib.jar (artifactType = jar)
  
  Secondary Variants (*)
  
      --------------------------------------------------
      Secondary Variant classes
      --------------------------------------------------
          Description = Directories containing compiled class files for main.
  
          Attributes
              - org.gradle.category            = library
              - org.gradle.dependency.bundling = external
              - org.gradle.jvm.version         = 11
              - org.gradle.libraryelements     = classes
              - org.gradle.usage               = java-api
          Artifacts
              - build/classes/java/main (artifactType = java-classes-directory)
  
  --------------------------------------------------
  Variant mainSourceElements (i)
  --------------------------------------------------
  Description = List of source directories contained in the Main SourceSet.
  
  Capabilities
      - new-java-library:lib:unspecified (default capability)
  Attributes
      - org.gradle.category            = verification
      - org.gradle.dependency.bundling = external
      - org.gradle.verificationtype    = main-sources
  Artifacts
      - src/main/java (artifactType = directory)
      - src/main/resources (artifactType = directory)
  
  --------------------------------------------------
  Variant runtimeElements
  --------------------------------------------------
  Description = Elements of runtime for main.
  
  Capabilities
      - new-java-library:lib:unspecified (default capability)
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  Artifacts
      - build/libs/lib.jar (artifactType = jar)
  
  Secondary Variants (*)
  
      --------------------------------------------------
      Secondary Variant classes
      --------------------------------------------------
          Description = Directories containing compiled class files for main.
  
          Attributes
              - org.gradle.category            = library
              - org.gradle.dependency.bundling = external
              - org.gradle.jvm.version         = 11
              - org.gradle.libraryelements     = classes
              - org.gradle.usage               = java-runtime
          Artifacts
              - build/classes/java/main (artifactType = java-classes-directory)
  
      --------------------------------------------------
      Secondary Variant resources
      --------------------------------------------------
          Description = Directories containing the project's assembled resource files for use at runtime.
  
          Attributes
              - org.gradle.category            = library
              - org.gradle.dependency.bundling = external
              - org.gradle.jvm.version         = 11
              - org.gradle.libraryelements     = resources
              - org.gradle.usage               = java-runtime
          Artifacts
              - build/resources/main (artifactType = java-resources-directory)
  
  --------------------------------------------------
  Variant testResultsElementsForTest (i)
  --------------------------------------------------
  Description = Directory containing binary results of running tests for the test Test Suite's test target.
  
  Capabilities
      - new-java-library:lib:unspecified (default capability)
  Attributes
      - org.gradle.category              = verification
      - org.gradle.testsuite.name        = test
      - org.gradle.testsuite.target.name = test
      - org.gradle.testsuite.type        = unit-test
      - org.gradle.verificationtype      = test-results
  Artifacts
      - build/test-results/test/binary (artifactType = directory)
  
  (i) Configuration uses incubating attributes such as Category.VERIFICATION.
  (*) Secondary variants are variants created via the Configuration#getOutgoing(): ConfigurationPublications API which also participate in selection, in addition to the configuration itself.
  ----
  
  From this you can see the two main variants that are exposed by a java library, `apiElements` and `runtimeElements`.
  Notice that the main difference is on the `org.gradle.usage` attribute, with values `java-api` and `java-runtime`.
  As they indicate, this is where the difference is made between what needs to be on the _compile_ classpath of consumers, versus what's needed on the _runtime_ classpath.
  
  It also shows _secondary_ variants, which are exclusive to Gradle projects and not published.
  For example, the secondary variant `classes` from `apiElements` is what allows Gradle to skip the JAR creation when compiling against a <<java_library_plugin.adoc#sec:java_library_classes_usage,`java-library` project>>.
  
  === Resolvable configurations report
  
  Gradle also offers a complimentary report task called `resolvableConfigurations` that displays the _resolvable_ configurations of a project, which are those which can have dependencies added and be resolved.  The report will list their attributes and any configurations that they extend.  It will also list a summary of any attributes which will be affected by <<variant_attributes.adoc#sec:abm_compatibility_rules, Compatibility Rules>> or <<variant_attributes.adoc#sec:abm_disambiguation_rules, Disambiguation Rules>> during resolution.
  
  By default, `resolvableConfigurations` prints information about all purely resolvable configurations.
  These are configurations that are marked resolvable but *not* marked consumable.
  Though some resolvable configurations are also marked consumable, these are legacy configurations that should *not* have dependencies added in build scripts.
  This report offers the optional parameter `--configuration <configurationName>` to select a single configuration to display.
  It also accepts the `--all` flag to include information about legacy and deprecated configurations.
  Finally, it accepts the `--recursive` flag to list in the extended configurations section those configurations which are extended _transitively_ rather than directly.
  
  Here is the output of the `resolvableConfigurations` task on a freshly generated `java-library` project:
  
  [listing]
  ----
  > Task :resolvableConfigurations
  --------------------------------------------------
  Configuration annotationProcessor
  --------------------------------------------------
  Description = Annotation processors and their dependencies for source set 'main'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  
  --------------------------------------------------
  Configuration compileClasspath
  --------------------------------------------------
  Description = Compile classpath for source set 'main'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = classes
      - org.gradle.usage               = java-api
  Extended Configurations
      - compileOnly
      - implementation
  
  --------------------------------------------------
  Configuration runtimeClasspath
  --------------------------------------------------
  Description = Runtime classpath of source set 'main'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  Extended Configurations
      - implementation
      - runtimeOnly
  
  --------------------------------------------------
  Configuration testAnnotationProcessor
  --------------------------------------------------
  Description = Annotation processors and their dependencies for source set 'test'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  
  --------------------------------------------------
  Configuration testCompileClasspath
  --------------------------------------------------
  Description = Compile classpath for source set 'test'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = classes
      - org.gradle.usage               = java-api
  Extended Configurations
      - testCompileOnly
      - testImplementation
  
  --------------------------------------------------
  Configuration testRuntimeClasspath
  --------------------------------------------------
  Description = Runtime classpath of source set 'test'.
  
  Attributes
      - org.gradle.category            = library
      - org.gradle.dependency.bundling = external
      - org.gradle.jvm.environment     = standard-jvm
      - org.gradle.jvm.version         = 11
      - org.gradle.libraryelements     = jar
      - org.gradle.usage               = java-runtime
  Extended Configurations
      - testImplementation
      - testRuntimeOnly
  
  --------------------------------------------------
  Compatibility Rules
  --------------------------------------------------
  Description = The following Attributes have compatibility rules defined.
  
      - org.gradle.dependency.bundling
      - org.gradle.jvm.environment
      - org.gradle.jvm.version
      - org.gradle.libraryelements
      - org.gradle.plugin.api-version
      - org.gradle.usage
  
  --------------------------------------------------
  Disambiguation Rules
  --------------------------------------------------
  Description = The following Attributes have disambiguation rules defined.
  
      - org.gradle.category
      - org.gradle.dependency.bundling
      - org.gradle.jvm.environment
      - org.gradle.jvm.version
      - org.gradle.libraryelements
      - org.gradle.plugin.api-version
      - org.gradle.usage
  ----
  
  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 metadata 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.
  
  [NOTE]
  .Relationship with Gradle Module Metadata
  ====
  Gradle Module Metadata is a metadata format for modules published on Maven, Ivy and other kinds of repositories.
  It is similar to the `pom.xml` or `ivy.xml` metadata file, but this format contains details about variants.
  
  See the {metadata-file-spec}[Gradle Module Metadata specification] for more information.
  ====
  
  [[sub:maven-mapping-to-variants]]
  === Mapping of Maven POM metadata to variants
  
  Modules published on a Maven repository are automatically converted into variant-aware modules.
  
  There is no way for Gradle to know which kind of component was published:
  - a BOM that represents a Gradle platform
  - a BOM used as a super-POM
  - a POM that is both a platform _and_ a library
  
  The default strategy used by Java projects in Gradle is to derive 8 different variants:
  
  * 2 "library" variants (attribute `org.gradle.category` = `library`)
  ** the `compile` variant maps the `<scope>compile</scope>` dependencies.
  