anchor.diff:  This variant is equivalent to the `runtimeElements` variant of the <<java_library_plugin.adoc#java_library_plugin,Java Library plugin>>.
   All dependencies of those scopes are considered _runtime dependencies_.
   - in both cases, the `<dependencyManagement>` dependencies are _not converted to constraints_
  +* a "sources" variant that represents the sources jar for the component
  +* a "javadoc" variant that represents the javadoc jar for the component
   * 4 "platform" variants derived from the `<dependencyManagement>` block (attribute `org.gradle.category` = `platform`):
   ** the `platform-compile` variant maps the  `<scope>compile</scope>` dependency management dependencies as _dependency constraints_.
   ** the `platform-runtime` variant maps both the `<scope>compile</scope>` and `<scope>runtime</scope>` dependency management dependencies as _dependency constraints_.
  
positive.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:mapping-maven-ivy-to-variants]]
  == Mapping from Maven/Ivy to variants
  
  Neither Maven nor Ivy have the concept of _variants_, which are only natively supported by Gradle Module Metadata.
  However, it doesn't prevent Gradle from working with them thanks to different strategies.
  
  [NOTE]
  .Relationship with Gradle Module Metadata
  ====
  Gradle Module Metadata is a metadata format for modules published on Maven, Ivy or other kind of repositories.
  It is similar to `pom.xml` or `ivy.xml` files, but this format is _aware of variants_.
  This means that if your project produces additional variants, those are available and published as part of the module metadata, which greatly improves the user experience.
  
  See the {metadata-file-spec}[Gradle Module Metadata specification] for more information.
  ====
  
  [[sub:maven-mapping-to-variants]]
  === Mapping of POM files to variants
  
  Modules published on a Maven repository are converted into variant-aware modules.
  A particularity of Maven modules is that there is no way to know what kind of component is published.
  In particular, there's no way to make the difference between a BOM representing a _platform_, and a BOM used as a super-POM.
  Sometimes, it is even possible for a POM file to act both as a platform _and_ a library.
  
  As a consequence, Maven modules are derived into 6 distinct variants, which allows Gradle users to explain precisely what they depend on:
  
  * 2 "library" variants (attribute `org.gradle.category` = `library`)
  ** the `compile` variant maps the `<scope>compile</scope>` dependencies.
  
negative.code: 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 has a fallback selection method. Gradle does _not_ perform variant aware resolution and instead selects either the `default` configuration or an explicitly named configuration.
  