PluginDependenciesSpec - Gradle DSL Version 4.5.1

# PluginDependenciesSpec

API Documentation: | `PluginDependenciesSpec`

Note: This class is incubating and may change in a future version of Gradle.

The DSL for declaring plugins to use in a script.

In a build script, the `plugins {}` script block API is of this type. That is, you can use this API in the body of the plugins script block to declare plugins to be used for the script.

### Relationship with the apply() method

The `plugins {}` block serves a similar purpose to the `PluginAware.apply(java.util.Map)` method that can be used to apply a plugin directly to a `Project` object or similar. A key difference is that plugins applied via the `plugins {}` block are conceptually applied to the script, and by extension the script target. At this time there is no observable practical difference between the two approaches with regard to the end result. The `plugins {}` block is a new, incubating, Gradle feature that will evolve to offer benefits over the `apply()` approach.

### Strict Syntax

The `plugins {}` block only allows a strict subset of the full build script programming language. Only the API of this type can be used, and values must be literal (e.g. constant strings, not variables). Moreover, the `plugins {}` block must be the first code of a build script. There is one exception to this, in that the `buildscript {`} block (used for declaring script dependencies) must precede it.

This implies the following constraints:

- Only `PluginDependenciesSpec.id(java.lang.String)` method calls may be top level statements
- `PluginDependenciesSpec.id(java.lang.String)` calls may only be followed by a `PluginDependencySpec.version(java.lang.String)` and/or `PluginDependencySpec.apply(boolean)` method call on the returned object
- `PluginDependenciesSpec.id(java.lang.String)`, `PluginDependencySpec.version(java.lang.String)` and `PluginDependencySpec.apply(boolean)` methods must be called with a literal argument (i.e. not a variable)
- The `plugins {}` script block must follow any `buildscript {}` script block, but must precede all other logic in the script

### Available Plugins

#### Core Plugins

Core Gradle plugins are able to be applied using the `plugins {}` block. Core plugins must be specified without a version number, and can have a qualified or unqualified id. That is, the `java` plugin can be used via:

    plugins {
      id 'java'
    }

Or via:

    plugins {
      id 'org.gradle.java'
    }

Core Gradle plugins use the `org.gradle` namespace.

For the list of available core plugins for a particular Gradle version, please consult the User Guide.

#### Community Plugins

Non-core plugins are available from the Gradle Plugin Portal. These plugins are contributed by users of Gradle to extend Gradle's functionality. Visit plugins.gradle.org to browse the available plugins and versions.

To use a community plugin, the fully qualified id must be specified along with a version.

### Properties

No properties

### Methods

Method | Description
`id(id)` | Incubating Add a dependency on the plugin with the given id.

### Script blocks

No script blocks

### Method details

#### `PluginDependencySpec` `id`(`String` id)

Note: This method is incubating and may change in a future version of Gradle.

Add a dependency on the plugin with the given id.

    plugins {
        id "org.company.myplugin"
    }

Further constraints (e.g. version number) can be specified by the methods of the return value.

    plugins {
        id "org.company.myplugin" version "1.3"
    }

Plugins are automatically applied to the current script by default. This can be disabled using the `apply false` option:

    plugins {
        id "org.company.myplugin" version "1.3" apply false
    }

This is useful to reuse task classes from a plugin or to apply it to some other target than the current script.