autonomousapps/gradle-glossary

'Artifact' is usually used in the context of publishing to designate a file whose name has a 'classifier' and 'extension'. Two artifacts in a Publication cannot have the same classifier and extension.

Confusingly, when used in the context of Maven coordinates, an artifactId refers to a list of the above artifacts. For an example, the okhttp artifactId contains jar, sources and javadocs artifacts.

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.

While the usage as a bucket of dependencies is the most common for Gradle users, configurations can also be used in other ways by plugin authors:

• as a FileCollection as an input to tasks (e.g. runtimeClasspath).

• as an outgoing variant to be later published (e.g. apiElements)

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.

Maven is a build tool like Gradle but using a more declarative syntax based on XML. For publishing dependencies, Maven uses the Maven publication format.

The Maven publication format is the format used by most of the JVM ecosystem to publish and consume binary dependencies. Each dependency is identified by a "$group:$artifact:$version string called "Maven coordinates". These dependencies can then be consumed by accessing files (by HTTP or on the local filesystem) at $root/$group/$version/. For an example, the files for com.squareup.okhttp3:okhttp:4.9.3 are available at https://repo.maven.apache.org/maven2/com/squareup/okhttp3/okhttp/4.9.3/

While originally made for the Maven build tool, Gradle also supports the Maven publication format. In order to provide more flexibility, Gradle also introduced Gradle module metadata to provide more information about the dependencies than a regular pom file

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. Other repositories exists like (now defunct) jcenter or the Google Maven repository.

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 Publication is a list of artifacts, and possibly associated metadata. Most of the times, you will deal with MavenPublications to publish in the Maven publication format with the maven-publish plugin

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.

A SoftwareComponent is a list of artifacts built by Gradle. It’s a relatively recent API used to connect outgoing configurations and publications. Most of the times, you will use already existing components such as java or the android ones to configure your maven publications. If you’re a plugin author, you will most likely deal with AdhowComponentWithVariants

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).