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: 
  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 nature of that information depends on what type of repository you publish the publication to. In the case of Maven, the information takes the form of a POM.
  
  One thing to bear in mind is that Maven repositories only allow a single _primary_ artifact, i.e. one with metadata, but they do allow _secondary_ artifacts such as packages of the associated source files and documentation ("-sources" and "-javadoc" JARs in the Java world).
  
  [[sub:terminology_repository]]
  == Repository
  
  A repository hosts a set of <<#sub:terminology_module,modules>>, each of which may provide one or many releases 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:resolution_rule]]
  == Resolution rule
  
  A resolution rule influences the behavior of how a <<#sub:terminology_dependency,dependency>> is resolved. Resolution rules are defined as part of the build logic. For more information, see <<customizing_dependency_resolution_behavior.adoc#customizing_dependency_resolution_behavior,Customizing Dependency Resolution Behavior>>.
  
  [[sub:terminology_transitive_dependency]]
  == Transitive dependency
  
  A <<#sub:terminology_module,module>> 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. However, the behavior is highly customizable.
  For more information, see <<dependency_constraints.adoc#,controlling transitive dependencies>>.
  
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
  