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: [[sub:ivy-mapping-to-variants]]
  === Mapping of Ivy files to variants
  
  Contrary to <<#sub:maven-mapping-to-variants, Maven>>, there is no derivation strategy implemented for Ivy files by default.
  The reason fo this is that, contrary to pom, Ivy is a flexible format that allows you to publish arbitrary many and customized _configurations_.
  So there is no notion of compile/runtime scope or compile/runtime variants in Ivy in general.
  Only if you use the <<publishing_ivy.adoc#publishing_ivy,ivy-publish plugin>> to publish ivy files with Gradle, you get a structure that follows a similar pattern as pom files.
  But since there is not guarantee that *all* ivy metadata files consumed by a build follow this pattern, Gradle cannot enforce a derivation strategy based on it.
  
  However, if you want to implement a derivation strategy for _compile_ and _runtime_ variants for Ivy, you can do so with <<component_metadata_rules.adoc#sec:component_metadata_rules,component metadata rule>>.
  The component metadata rules API allows you to <<component_metadata_rules.adoc#sec:component_metadata_rules_details,access ivy configurations>> and create variants based on them.
  If you know that all the ivy modules your are consuming have been published with Gradle without further customizations of the `ivy.xml` file, you can add the following rule to your build:
  
  .Deriving compile and runtime variants for Ivy metadata
  ====
  
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.
  