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 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.
A capability identifies a feature offered by one or multiple components.
A capability is identified by coordinates similar to the coordinates used for a module versions.
By default, each module version offers a capability that matches its coordinates, for example
Capabilities can be used to express that a component provides multiple feature variants or that two different components implement the same feature (and thus cannot be used together).
For more details, see the section on capabilities.
Any single version of a module.
For external libraries, the term component refers to one published version of the library.
In a build, components are defined by plugins (e.g. the Java Library plugin) and provide a simple way to define a publication for publishing.
They comprise artifacts as well as the appropriate metadata that describes a component’s variants in detail.
For example, the
java component in its default setup consists of a JAR — produced by the
jar task — and the dependency information of the Java api and runtime variants.
It may also define additional variants, for example sources and Javadoc, with the corresponding artifacts.
A configuration is a named set of dependencies grouped together for a specific goal. Configurations provide access to the underlying, resolved modules and their artifacts. For more information, see the sections on dependency configurations as well as resolvable and consumable 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 sections on upgrading and downgrading transitive dependencies.
A feature variant is a variant representing a feature of a component that can be individually selected or not. A feature variant is identified by one or more capabilities. For more information, see the sections on modeling feature variants and optional dependencies.
Releases of a module provide metadata.
Metadata is the data that describes the module in more detail e.g. information about the location of artifacts or required transitive dependencies.
Gradle offers its own metadata format called Gradle Module Metadata (
.module file) but also supports Maven (
.pom) and Ivy (
See the section on understanding Gradle Module Metadata for more information on the supported metadata formats.
A component metadata rule is a rule that modifies a component’s metadata after it was fetched from a repository, e.g. to add missing information or to correct wrong information. In contrast to 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 fixing metadata with component metadata rules.
A module version represents a distinct set of changes of a released module.
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
groovy1.2, also use
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 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 metadata).
A repository hosts a set of modules, each of which may provide one or many releases (components) 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 variant of a component 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. The version selection for transitive dependencies can be influenced by declaring dependency constraints.
Gradle’s dependency resolution is variant-aware and selects one or more variants of each component after a component (i.e. one version of a module) has been selected. It may also fail if the variant selection result is ambiguous, meaning that Gradle does not have enough information to select one of multiple mutual exclusive variants. In that case, more information can be provided through variant attributes. Examples of variants each Java components typically offers are api and runtime variants. Others examples are JDK8 and JDK11 variants. For more information, see the section on variant selection.
Attributes are used to identify and select variants.
A variant has one or more attributes defined, for example
When dependencies are resolved, a set of attributes are requested and Gradle finds the best fitting variant(s) for each component in the dependency graph.
Compatibility and disambiguation rules can be implemented for an attribute to express compatibility between values (e.g. Java 8 is compatible with Java 11, but Java 11 should be preferred if the requested version is 11 or higher).
Such rules are typically provided by plugins.
For more information, see the sections on variant selection and declaring attributes.