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 is a pointer to another piece of software required to build, test or run a module. For more information, see Declaring Dependencies.

Dependency constraint

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.


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.

Module metadata

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 ivy.xml.

Module version

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 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 platform is a set of modules aimed to be used together. There are different categories of platforms, corresponding to different use cases:

  • module set: often a set of modules published together as a whole. Using one module of the set often means we want to use the same version for all modules of the set. For example, if using groovy 1.2, also use groovy-json 1.2.

  • runtime environment: a set of libraries known to work well together. e.g., the Spring Platform, recommending versions for both Spring and components that work well with Spring.

  • deployment environment: Java runtime, application server, …​

In addition Gradle defines virtual platforms.

Maven’s BOM (bill-of-material) is a popular kind of platform that Gradle supports.


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.

Resolution rule

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.

Transitive dependency

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.