# The Base Plugin

version 9.2.0

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.

## Usage

Example 1. Applying the Base Plugin
build.gradle.kts

    plugins {
        base
    }

build.gradle

    plugins {
        id 'base'
    }

## Task

`clean` — `Delete`

  Deletes the build directory and everything in it, i.e. the path specified by the layout.buildDirectory 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)`.

`assemble` — lifecycle 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, `buildRuntimeElements` will execute any task that is required to create any artifact attached to the `runtimeElements` 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:

`default`

  A fallback configuration used when dependency resolution is performed without request attributes.

  New builds and plugins should not be using the `default` configuration! It remains solely for backwards compatibility. Dependency resolution should be performed with request attributes.

`archives`

  All artifacts defined on the `archives` configuration are automatically built by the `assemble` task.

  New builds and plugins should not be using the `archives` configuration! It remains solely for backwards compatibility. Instead, task dependencies should be declared directly on the `assemble` task.

## 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
build.gradle.kts

    base {
        archivesName = "gradle"
        distsDirectory = layout.buildDirectory.dir("custom-dist")
        libsDirectory = layout.buildDirectory.dir("custom-libs")
    }

build.gradle

    base {
        archivesName = "gradle"
        distsDirectory = layout.buildDirectory.dir('custom-dist')
        libsDirectory = layout.buildDirectory.dir('custom-libs')
    }

`archivesName` — default: `$project.name`

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

`distsDirectory` — default: `layout.buildDirectory.dir("distributions")`

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

`libsDirectory` — default: `layout.buildDirectory.dir("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:

`destinationDirectory`

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

`archiveVersion`

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

`archiveBaseName`

  Defaults to `archivesName`.