The Base Plugin provides some tasks and conventions that are common to most builds and adds a structure to the build that promotes consistency in how they are run. Its most significant contribution is a set of lifecycle tasks that act as an umbrella for the more specific tasks provided by other plugins and build authors.


Example 1. Applying the Base Plugin
plugins {
    id 'base'
plugins {



Deletes the build directory and everything in it, i.e. the path specified by the Project.getBuildDir() project property.

check — lifecycle task

Plugins and build authors should attach their verification tasks, such as ones that run tests, to this lifecycle task using check.dependsOn(task).

assemblelifecycle task

Plugins and build authors should attach tasks that produce distributions and other consumable artifacts to this lifecycle task. For example, jar produces the consumable artifact for Java libraries. Attach tasks to this lifecycle task using assemble.dependsOn(task).

build — lifecycle task

Depends on: check, assemble

Intended to build everything, including running all tests, producing the production artifacts and generating documentation. You will probably rarely attach concrete tasks directly to build as assemble and check are typically more appropriate.

buildConfiguration — task rule

Assembles those artifacts attached to the named configuration. For example, buildArchives will execute any task that is required to create any artifact attached to the archives configuration.

cleanTask — task rule

Removes the defined outputs of a task, e.g. cleanJar will delete the JAR file produced by the jar task of the Java Plugin.

Dependency management

The Base Plugin adds no configurations for dependencies, but it does add the following configurations:


A fallback configuration used by consumer projects. Let’s say you have project B with a project dependency on project A. Gradle uses some internal logic to determine which of project A’s artifacts and dependencies are added to the specified configuration of project B. If no other factors apply — you don’t need to worry what these are — then Gradle falls back to using everything in project A’s default configuration.

New builds and plugins should not be using the default configuration! It remains for the reason of backwards compatibility.


A standard configuration for the production artifacts of a project.

Note that the assemble task generates all artifacts that are attached to the archives configuration.

Contributed extensions

The Base Plugin adds the base extension to the project. This allows to configure the following properties inside a dedicated DSL block.

Example 2. Using the base extension
base {
    archivesName = "gradle"
    distsDirectory = layout.buildDirectory.dir('custom-dist')
    libsDirectory = layout.buildDirectory.dir('custom-libs')
base {
archivesName — default: $

Provides the default AbstractArchiveTask.getArchiveBaseName() for archive tasks.

distsDirectory — default: $buildDir/distributions

Default name of the directory in which distribution archives, i.e. non-JARs, are created.

libsDirectory — default: $buildDir/libs

Default name of the directory in which library archives, i.e. JARs, are created.

The plugin also provides default values for the following properties on any task that extends AbstractArchiveTask:


Defaults to distsDirectory for non-JAR archives and libsDirectory for JARs and derivatives of JAR, such as WARs.


Defaults to $project.version or 'unspecified' if the project has no version.


Defaults to $archivesBaseName.

Conventions (deprecated)

The Base Plugin also adds conventions related to the creation of archives, such as ZIPs, TARs and JARs. These are deprecated and superseded by the extension described above. See the BasePluginConvention DSL documentation for information on them.