martinbonnin / gradle-glossary Goto Github PK

A 'build' is the aggregate of the atomic pieces of work performed by Gradle. A build is made up of projects and those projects have a collection of tasks. A build usually has an outcome of SUCCESS or FAILURE. You can run a build using the gradle or gradlew commands.

A build.gradle script. The existence of a build script, along with an entry in the settings script (other than for the root build script, which requires no entry), is what defines a Gradle module.

A Configuration, at the most basic level, is a bucket of dependencies. The most common configurations, which most people would have seen, are api and implementation. A great place to learn more about configurations is the documentation for the java-library plugin.

The word "configuration" is one of the most overloaded in the Gradle world. See also configuration phase.

A Gradle build is composed of two primary phases, the configuration phase (not to be confused with Configuration instances) and the execution phase. The configuration phase happens first and is single-threaded.

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

See also Herding elephants: Wrangling a 3,500-module Gradle project.

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 itself, 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. This phase has multiple levels of parallelism.

Gradle is the open-source build system developed and maintained by Gradle, Inc., a for-profit company.

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

See also Plugin.

An informal term for a Project, but more common than the formal term. A module is a source code-containing directory, more or less independent of other modules in the same multi-module (or multi-project) project.

This is one of the other very heavily overloaded terms in the Gradle world. See also Project.

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.

There are three kinds of plugin, based on the context in which they are applied:

1. Project plugins that implement Plugin<Project>, applied in build scripts.

2. Settings plugins that implement Plugin<Settings>, applied in settings scripts.

3. Init (Gradle) plugins that implement Plugin<Gradle>, applied in init scripts.

Plugins may be implemented as so-called binary plugins (that is, by explicitly implementing one of the specific generic interfaces described above), or as precompiled script plugins. This distinction is merely an implementation detail.

cf. script plugins.

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. The most common type of Plugin is a project plugin. Most Gradle projects are composed of many projects (sometimes called "subprojects").

A gradle script that can be applied to other gradle scripts, including build scripts, settings scripts, and init scripts. Can be written in Groovy or Kotlin, and are applied to other scripts via PluginAware.apply. For example, apply from: 'complicated_thing.gradle'. Depending on the type of script they are applied to, they’re backed by either a Project instance, a Settings instance, or a Gradle instance.

A settings.gradle script. A settings script has a large number of responsibilities, but one of the most important is declaring the set of projects that are part of the build, via include ':project1' and so on.

Each projects is made up of one or more tasks. Each task ought to be atomic (but often isn’t), with inputs and outputs. Gradle executes tasks to perform its work. Task examples include: compiling source code, creating artifacts (such as jars or apks), generating Javadoc, running static analysis (e.g. lint), deleting temporary files, or publishing to a repository, etc. When a Gradle task is asked to run we can see the outcome of the task. This will be one of EXECUTED, SKIPPED, FAILED, FROM-CACHE, UP-TO-DATE, NO-SOURCE or blank (meaning executed).