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.
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:
-
Project plugins that implement
Plugin<Project>
, applied in build scripts. -
Settings plugins that implement
Plugin<Settings>
, applied in settings scripts. -
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.
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).