anchor.diff:  == 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>>.
  +For more information, see the section on <<declaring_dependencies.adoc#,declaring dependencies>>.
   
   [[sub:terminology_dependency_constraint]]
   == Dependency constraint
  
positive.code: 
  = Dependency Management Terminology
  
  Dependency management comes with a wealth of terminology. Here you can find the most commonly-used terms including references to the user guide to learn about their practical application.
  
  [[sub:terminology_artifact]]
  == Artifact
  
  A file or directory produced by a build, such as a JAR, a ZIP distribution, or a native executable.
  
  Artifacts are typically designed to be used or consumed by users or other projects, or deployed to hosting systems. In such cases, the artifact is a single file. Directories are common in the case of inter-project dependencies to avoid the cost of producing the publishable artifact.
  
  [[sub:terminology_component]]
  == Component
  
  Any single version of a <<dependency_management_terminology.adoc#sub:terminology_module,module>>.
  
  Components are defined by plugins and provide a simple way to define a publication for publishing.
  They comprise one or more <<#sub:terminology_artifact,artifacts>> as well as the appropriate metadata.
  For example, the `java` component consists of the production JAR — produced by the `jar` task — and its dependency information.
  
  [[sub:terminology_configuration]]
  == Configuration
  
  A configuration is a named set of <<#sub:terminology_dependency,dependencies>> grouped together for a specific goal: For example the `implementation` configuration represents the set of dependencies required to compile a project.
  Configurations provide access to the underlying, resolved <<#sub:terminology_module,modules>> and their artifacts.
  For more information, see <<declaring_dependencies.adoc#sec:what-are-dependency-configurations,What are dependency configurations>>.
  
  [NOTE]
  ====
  
negative.code: 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 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>>.
  
  [[sub:terminology_module_metadata]]
  == Module metadata
  
  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].
  
  [[sub::terminology_platform]]
  == Platform
  