anchor.diff:  A dependency constraint defines requirements that need to be met by a module to make it a valid resolution result for the dependency.
   For example, a dependency constraint can narrow down the set of supported module versions.
   Dependency constraints can be used to express such requirements for transitive dependencies.
  -For more information, see <<dependency_constraints.adoc#sec:adding-constraints-transitive-deps,Adding constraints on transitive dependencies>>.
  +For more information, see the sections on <<dependency_constraints.adoc#,upgrading>> and <<dependency_downgrade_and_exclude.adoc#,downgrading>> transitive dependencies.
  +
  +[[sub:terminology_feature_variant]]
  +== Feature Variant
  +
  +A feature variant is a <<#sub:terminology_variant,variant>> representing a feature of a component that can be individually selected or not.
  +A feature variant is identified by one or more <<#sub:terminology_capability,capabilities>>.
  +A For more information, see the sections on <<feature_variants.adoc#,modeling feature variants and optional dependencies>>.
   
   [[sub:terminology_module]]
   == Module
   
  -A piece of software that evolves over time e.g. link:https://github.com/google/guava[Google Guava]. Every module has a name. Each release of a module is optimally represented by a <<#sub:terminology_module_version,module version>>. For convenient consumption, modules can be hosted in a <<#sub:terminology_repository,repository>>.
  +A piece of software that evolves over time e.g. link:https://github.com/google/guava[Google Guava].
  +Every module has a name. Each release of a module is optimally represented by a <<#sub:terminology_module_version,module version>>.
  +For convenient consumption, modules can be hosted in a <<#sub:terminology_repository,repository>>.
   
   [[sub:terminology_module_metadata]]
   == Module metadata
   
  -Releases of a <<#sub:terminology_module,module>> can provide metadata. Metadata is the data that describes the module in more detail e.g. the coordinates for locating it in a repository, information about the project or required <<#sub:terminology_transitive_dependency,transitive dependencies>>. In Maven the metadata file is called `.pom`, in Ivy it is called `ivy.xml`.
  +Releases of a <<#sub:terminology_module,module>> provide metadata.
  +Metadata is the data that describes the module in more detail e.g. information about the location of artifacts or required <<#sub:terminology_transitive_dependency,transitive dependencies>>.
  +Gradle offers it's own metadata format called link:https://github.com/gradle/gradle/blob/master/subprojects/docs/src/docs/design/gradle-module-metadata-latest-specification.md[Gradle Module Metadata] (`.module` file) but also supports Maven (`.pom`) and Ivy (`ivy.xml`) metadata.
  +See the section on <<publishing_gradle_module_metadata.adoc#,understanding Gradle Module Metadata>> for more information on the supported metadata formats.
  +
  +== Component metadata rule
  +
  +A component metadata rule is a rule that modifies a component's metad
  +ata after it was fetched from a repository, e.g. to add missing information or to correct wrong information.
  +In contrast to <<#sub:terminology_resolution_rule,resolution rules>>, component metadata rules are applied *before* resolution starts.
  +Component metadata rules are defined as part of the build logic and can be shared through plugins.
  +For more information, see the section on <<component_metadata_rules.adoc#,fixing metadata with component metadata rules>>.
   
   [[sub:terminology_module_version]]
   == Module version
   
  -A module version represents a distinct set of changes of a released <<#sub:terminology_module,module>>. For example `18.0` represents the version of the module with the coordinates `com.google:guava:18.0`. In practice there's no limitation to the scheme of the module version. Timestamps, numbers, special suffixes like `-GA` are all allowed identifiers. The most widely-used versioning strategy is link:https://semver.org/[semantic versioning].
  +A module version represents a distinct set of changes of a released <<#sub:terminology_module,module>>.
  +For example `18.0` represents the version of the module with the coordinates `com.google:guava:18.0`.
  +In practice there's no limitation to the scheme of the module version.
  +Timestamps, numbers, special suffixes like `-GA` are all allowed identifiers.
  +The most widely-used versioning strategy is link:https://semver.org/[semantic versioning].
   
   [[sub::terminology_platform]]
   == Platform
  
positive.code: == Dependency
  
  A dependency is a pointer to another piece of software required to build, test or run a <<#sub:terminology_module,module>>.
  For more information, see <<declaring_dependencies.adoc#,Declaring Dependencies>>.
  
  [[sub:terminology_dependency_constraint]]
  == Dependency constraint
  
negative.code: 
  A description of the files and metadata that should be published to a repository as a single entity for use by consumers.
  
  A publication has a name and consists of one or more artifacts plus information about those artifacts (the <<#sub:terminology_module_metadata,metadata>>).
  
  [[sub:terminology_repository]]
  == Repository
  
  A repository hosts a set of <<#sub:terminology_module,modules>>, each of which may provide one or many releases (components) indicated by a <<#sub:terminology_module_version,module version>>.
  The repository can be based on a binary repository product (e.g. Artifactory or Nexus) or a directory structure in the filesystem.
  For more information, see <<declaring_repositories.adoc#,Declaring Repositories>>.
  
  [[sub:terminology_resolution_rule]]
  == Resolution rule
  
  A resolution rule influences the behavior of how a <<#sub:terminology_dependency,dependency>> is resolved directly.
  Resolution rules are defined as part of the build logic.
  For more information, see the section on <<resolution_rules.adoc#,customizing resolution of a dependency directly>>.
  
  [[sub:terminology_transitive_dependency]]
  == Transitive dependency
  
  A variant of a <<#sub:terminology_component,component>> can have dependencies on other modules to work properly, so-called transitive dependencies.
  Releases of a module hosted on a <<#sub:terminology_repository,repository>> can provide <<#sub:terminology_module_metadata,metadata>> to declare those transitive dependencies.
  By default, Gradle resolves transitive dependencies automatically.
  The version selection for transitive dependencies can be influenced by declaring <<dependency_constraints.adoc#,dependency constraints>>.
  
  [[sub:terminology_variant]]
  == Variant (of a component)
  
  Each <<#sub:terminology_component,component>> consists of one or more variants.
  A variant consists of a set of artifacts and defines a set of dependencies.
  It is identified by a set of <<sub:terminology_attribute,attributes>> and <<sub:terminology_capability,capabilities>>.
  
  Gradle's dependency resolution is variant-aware and selects one or more variants of each component after a component (i.e. one version of a module) has been selected.
  It may also fail if the variant selection result is ambiguous, meaning that Gradle does not have enough information to select one of multiple mutual exclusive variants.
  In that case, more information can be provided through <<#sub:terminology_attribute,variant attributes>>.
  Examples of variants each Java components typically offers are _api_ and _runtime_ variants.
  Others examples are JDK8 and JDK11 variants.
  For more information, see the section on <<variant_model.adoc#,variant selection>>.
  
  [[sub:terminology_attribute]]
  == Variant Attribute
  
  Attributes are used to identify and select <<#sub:terminology_variant,variants>>.
  A variant has one or more attributes defined, for example `org.gradle.usage=java-api`, `org.gradle.jvm.version=11`.
  When dependencies are resolved, a set of attributes are requested and Gradle finds the best fitting variant(s) for each component in the dependency graph.
  Compatibility and disambiguation rules can be implemented for an attribute to express compatibility between values (e.g. Java 8 is compatible with Java 11, but Java 11 should be preferred if the requested version is 11 or higher).
  Such rules are typically provided by plugins.
  For more information, see the sections on <<variant_model.adoc#,variant selection>> and <<variant_attributes.adoc#,declaring attributes>>.
  