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.
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 Dependency Constraints.
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 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.