Table of Contents
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.
A configuration is a named set of 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 modules and their artifacts. For more information, see Managing Dependency Configurations.
The word "configuration" is an overloaded term and has a different meaning outside of the context of dependency management.
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 section called “Managing versions of transitive dependencies with dependency constraints”.
A piece of software that evolves over time e.g. Google Guava. Every module has a name. Each release of a module is optimally represented by a module version. For convenient consumption, modules can be hosted in a repository.
Releases of a 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 transitive dependencies. In Maven the metadata file is called
.pom, in Ivy it is called
A module version represents a distinct set of changes of a released 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 semantic versioning.
A repository hosts a set of modules, each of which may provide one or many releases indicated by a 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.
A resolution rule influences the behavior of how a dependency is resolved. Resolution rules are defined as part of the build logic. For more information, see Customizing Dependency Resolution Behavior.
A module can have dependencies on other modules to work properly, so-called transitive dependencies. Releases of a module hosted on a repository can provide metadata to declare those transitive dependencies. By default, Gradle resolves transitive dependencies automatically. However, the behavior is highly customizable. For more information, see Managing Transitive Dependencies.