Glossary

A file or directory produced by a build, such as a JAR, a ZIP distribution, or a native executable.

A build is the aggregate of the atomic pieces of work performed by Gradle. It is made up of projects and those projects have a collection of tasks.

A Build Scan is a service provided by Gradle which is used to identify build issues and build performance.

A build.gradle script.

A capability identifies a feature offered by one or multiple components. A capability is identified by coordinates similar to the coordinates used for module versions. By default, each module version offers a capability that matches its coordinates, such as com.google:guava:18.0. 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.

A component metadata rule is a rule that modifies a component’s metadata after it is fetched from a repository, e.g., to add missing information or correct incorrect 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 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.

A Gradle build is composed of two primary phases, the configuration phase (not to be confused with [sub:terminology_configuration] instances) and the execution phase.

A plugin built on top of an ecosystem plugin, which applies common conventions to the build script that uses the plugin.

See Cross-Project Configuration.

Cross-project configuration refers to managing and customizing multiple subprojects within a multi-project build.

subprojects {
    apply plugin: 'java'
    repositories {
        mavenCentral()
    }
    dependencies {
        testImplementation 'junit:junit:4.13.2'
    }
}

gradle.lifecycle.beforeProject {
    repositories {
        mavenCentral()
    }
}

tasks.register("customTask") {
    // Avoid this! Directly accessing outputs from another subproject's task
    def outputFile = project(":subprojectB").tasks.named("someTask").get().outputs.files.singleFile
    inputs.file(outputFile)
    doLast {
        println("Processing file from subprojectB: ${outputFile}")
    }
}

tasks.register("someTask") {
    def outputFile = layout.buildDirectory.file("output.txt")
    outputs.file(outputFile)
    doLast {
        outputFile.get().asFile.text = "Output from subprojectB"
        println("Generated output file in subprojectB: ${outputFile.get().asFile}")
    }
}

A dependency is a pointer to another piece of software required to build, test, or run a module. For more information, see the section on declaring dependencies.

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.

Many Gradle APIs come in two forms: eager and lazy. The difference lies in when values are calculated or resolved.

// Eager: evaluated as soon as the build script runs
val myValue = file("output.txt")
// Lazy: evaluated only when required
val myValue = layout.buildDirectory.file("output.txt")

A plugin responsible for building a language, such as Java (java and java-library), Groovy, Scala, Android, Kotlin, etc. Many plugins are maintained by Gradle and are part of the Gradle distribution.

The second primary phase of a Gradle build, the execution phase happens after the configuration phase is complete. This is where all tasks actions are executed.

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.

A Gradle build can consist of one or more Gradle projects and is typically configured using a settings.gradle(.kts) file at the root.

An incremental build executes only the tasks that are necessary. If we run any source code, Gradle first checks if that source code has gone through any previous execution. If the code has some changes, it will then be executed, but if there are no changes, then it will skip the execution of that code.

An init or initialization script, is backed by an instance of the Gradle type.

Many Gradle APIs come in two forms: eager and lazy. The difference lies in when values are calculated or resolved.

// Lazy: evaluated only when required
val myValue = layout.buildDirectory.file("output.txt")
// Eager: evaluated as soon as the build script runs
val myValue = file("output.txt")

MavenCentral is the main repository that hosts Maven publications. It is operated by a company named Sonatype and is the default repository for a lot of the ecosystem.

A piece of software that evolves over time e.g., Google Guava. Every module has a name. Each module release is optimally represented by a module version. For convenient consumption, modules can be hosted in a repository.

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 (ivy.xml) metadata. See the section on understanding Gradle Module Metadata for more information on the supported metadata formats.

A module version represents a distinct set of changes of a released module. For example, 18.0 represents the module version with the coordinates com.google:guava:18.0. In practice, there are no limitations to the scheme of the module version. Timestamps, numbers, and 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:

Gradle is built on a plugin system. Gradle itself is primarily composed of infrastructure, such as a sophisticated dependency resolution engine, common to all project types. The rest of its functionality comes from plugins, including "core" plugins distributed with Gradle itself, third-party plugins, and script plugins in a given build.

Equivalent to a plugin, but written such that it looks like a build script, precompiled script plugins can be written in Groovy or Kotlin by applying the groovy-gradle-plugin or kotlin-dsl plugin, respectively.

Often referred to as a "module", every Gradle project is backed by a Project instance, hence the name.

A description of the files and metadata that should be published to a repository as a single entity for use by consumers.