Gradle 带有一套强大的核心系统，例如依赖管理、任务执行和项目配置。但它可以做的其他一切都是由插件提供的。

插件封装了特定任务或集成的逻辑，例如编译代码、运行测试或部署工件。通过应用插件，用户可以轻松地向其构建过程添加新功能，而无需从头开始编写复杂的代码。

这种基于插件的方法使 Gradle 变得轻量级且模块化。它还促进了代码重用和可维护性，因为插件可以在项目之间或组织内部共享。

在阅读本章之前，建议您先阅读 学习基础知识 并完成 教程。

插件介绍

插件可以来自 Gradle 或 Gradle 社区。但是，当用户想要组织其构建逻辑或需要现有插件未提供的特定构建功能时，他们可以开发自己的插件。

因此，我们区分三种不同类型的插件

  1. 核心插件 - 来自 Gradle 的插件。

  2. 社区插件 - 来自 Gradle 插件门户 或公共存储库的插件。

  3. 本地或自定义插件 - 您自己开发的插件。

核心插件

术语 **核心插件** 指的是 Gradle 发行版中包含的插件，例如 Java 库插件。它们始终可用。

社区插件

术语 **社区插件** 指的是发布到 Gradle 插件门户（或其他公共存储库）的插件，例如 Spotless 插件。

本地或自定义插件

术语 **本地或自定义插件** 指的是您自己为自己的构建编写的插件。

自定义插件

**自定义插件** 有三种类型

# 类型 位置 最有可能 好处

1

构建脚本和脚本插件

构建脚本或脚本

本地插件

插件会自动编译并包含在构建脚本的类路径中。

2

预编译脚本插件

buildSrc 文件夹或 复合 构建

约定插件

插件会自动编译、测试，并在构建脚本的类路径中可用。该插件对构建使用的每个构建脚本可见。

3

二进制插件

独立项目

共享插件

插件 JAR 会被生成并发布。该插件可以在多个构建中使用，并与其他人共享。

构建脚本和脚本插件

**构建脚本插件** 通常是小型本地插件，在构建文件中编写，用于特定于单个构建或项目的任务，不需要在多个项目中重复使用。构建脚本插件不推荐使用，但许多其他形式的插件都从构建脚本插件演变而来。

要创建 Gradle 插件，您需要在构建文件中编写一个实现 Plugin 接口的类。

以下示例创建了一个 GreetingPlugin，它向项目添加了一个 hello 任务

build.gradle.kts
class GreetingPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.task("hello") {
            doLast {
                println("Hello from the GreetingPlugin")
            }
        }
    }
}

// Apply the plugin
apply<GreetingPlugin>()
build.gradle
class GreetingPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.task('hello') {
            doLast {
                println 'Hello from the GreetingPlugin'
            }
        }
    }
}

// Apply the plugin
apply plugin: GreetingPlugin
$ gradle -q hello
Hello from the GreetingPlugin

Project 对象作为参数传递给 apply()，插件可以使用它来配置项目，无论它需要什么（例如添加任务、配置依赖项等）。

**脚本插件** 与构建脚本插件类似，但是，插件定义只是在一个单独的脚本中完成，然后使用 apply(from = " ") 或 apply from: '' 应用于构建文件：脚本插件不推荐使用。

other.gradle.kts
class GreetingScriptPlugin : Plugin<Project> {
    override fun apply(project: Project) {
        project.task("hi") {
            doLast {
                println("Hi from the GreetingScriptPlugin")
            }
        }
    }
}

// Apply the plugin
apply<GreetingScriptPlugin>()
other.gradle
class GreetingScriptPlugin implements Plugin<Project> {
    void apply(Project project) {
        project.task('hi') {
            doLast {
                println 'Hi from the GreetingScriptPlugin'
            }
        }
    }
}

// Apply the plugin
apply plugin: GreetingScriptPlugin
build.gradle.kts
apply(from = "other.gradle.kts")
build.gradle
apply from: 'other.gradle'
$ gradle -q hi
Hi from the GreetingScriptPlugin

预编译脚本插件

预编译脚本插件 在执行之前被编译成类文件并打包到 JAR 中。这些插件使用 Groovy 或 Kotlin DSL 而不是纯 Java、Kotlin 或 Groovy。它们最适合用作约定插件，在项目之间共享构建逻辑，或者作为一种整齐地组织构建逻辑的方式。

要创建预编译脚本插件，您可以

  1. 使用 Gradle 的 Kotlin DSL - 插件是一个 .gradle.kts 文件，并应用 id("kotlin-dsl")。

  2. 使用 Gradle 的 Groovy DSL - 插件是一个 .gradle 文件，并应用 id("groovy-gradle-plugin")。

要应用预编译脚本插件，您需要知道它的 ID。ID 来自插件脚本的文件名及其（可选）包声明。

例如，脚本 src/main/*/java-library.gradle(.kts) 的插件 ID 为 java-library（假设它没有包声明）。同样，src/main/*/my/java-library.gradle(.kts) 的插件 ID 为 my.java-library，只要它具有 my 的包声明。

预编译脚本插件名称有两个重要的限制

  • 它们不能以 org.gradle 开头。

  • 它们不能与 核心插件 的名称相同。

当插件应用于项目时，Gradle 会创建插件类的实例并调用实例的 Plugin.apply() 方法。

每个应用该插件的项目都会创建一个新的 Plugin 实例。

让我们将 GreetingPlugin 脚本插件重写为预编译脚本插件。由于我们使用的是 Groovy 或 Kotlin DSL，因此该文件本质上变成了插件。原始脚本插件只是创建了一个 hello 任务，该任务打印问候语，这就是我们在预编译脚本插件中要做的

buildSrc/src/main/kotlin/GreetingPlugin.gradle.kts
tasks.register("hello") {
    doLast {
        println("Hello from the convention GreetingPlugin")
    }
}
buildSrc/src/main/groovy/GreetingPlugin.gradle
tasks.register("hello") {
    doLast {
        println("Hello from the convention GreetingPlugin")
    }
}

现在可以使用 GreetingPlugin 的 ID 在其他子项目的构建中应用它

app/build.gradle.kts
plugins {
    application
    id("GreetingPlugin")
}
app/build.gradle
plugins {
    id 'application'
    id('GreetingPlugin')
}
$ gradle -q hello
Hello from the convention GreetingPlugin

约定插件

约定插件 通常是一个预编译脚本插件，它使用您自己的约定（即默认值）配置现有的核心和社区插件，例如使用 java.toolchain.languageVersion = JavaLanguageVersion.of(17) 设置 Java 版本。约定插件还用于强制执行项目标准并帮助简化构建过程。它们可以应用和配置插件、创建新的任务和扩展、设置依赖项等等。

让我们以一个包含三个子项目的示例构建为例：一个用于 data-model，一个用于 database-logic，一个用于 app 代码。该项目具有以下结构

.
├── buildSrc
│   ├── src
│   │   └──...
│   └── build.gradle.kts
├── data-model
│   ├── src
│   │   └──...
│   └── build.gradle.kts
├── database-logic
│   ├── src
│   │   └──...
│   └── build.gradle.kts
├── app
│   ├── src
│   │   └──...
│   └── build.gradle.kts
└── settings.gradle.kts

database-logic 子项目的构建文件如下所示

database-logic/build.gradle.kts
plugins {
    id("java-library")
    id("org.jetbrains.kotlin.jvm") version "1.9.23"
}

repositories {
    mavenCentral()
}

java {
    toolchain.languageVersion.set(JavaLanguageVersion.of(11))
}

tasks.test {
    useJUnitPlatform()
}

kotlin {
    jvmToolchain(11)
}

// More build logic
database-logic/build.gradle
plugins {
    id 'java-library'
    id 'org.jetbrains.kotlin.jvm' version '1.9.23'
}

repositories {
    mavenCentral()
}

java {
    toolchain.languageVersion.set(JavaLanguageVersion.of(11))
}

tasks.test {
    useJUnitPlatform()
}

kotlin {
    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(11))
    }
}

// More build logic

我们应用了java-library插件并添加了org.jetbrains.kotlin.jvm插件以支持Kotlin。我们还配置了Kotlin、Java、测试等。

我们的构建文件开始变大了…​

我们应用的插件越多，配置的插件越多，它就越大。app和data-model子项目的构建文件中也存在重复，尤其是在配置通用扩展（如设置Java版本和Kotlin支持）时。

为了解决这个问题，我们使用约定插件。这使我们能够避免在每个构建文件中重复配置，并使我们的构建脚本更加简洁和易于维护。在约定插件中，我们可以封装任意构建配置或自定义构建逻辑。

为了开发约定插件，我们建议使用buildSrc——它代表一个完全独立的Gradle构建。buildSrc有自己的设置文件来定义此构建的依赖项的位置。

我们在buildSrc/src/main/kotlin目录中添加一个名为my-java-library.gradle.kts的Kotlin脚本。或者相反，在buildSrc/src/main/groovy目录中添加一个名为my-java-library.gradle的Groovy脚本。我们将database-logic构建文件中的所有插件应用和配置都放入其中

buildSrc/src/main/kotlin/my-java-library.gradle.kts
plugins {
    id("java-library")
    id("org.jetbrains.kotlin.jvm")
}

repositories {
    mavenCentral()
}

java {
    toolchain.languageVersion.set(JavaLanguageVersion.of(11))
}

tasks.test {
    useJUnitPlatform()
}

kotlin {
    jvmToolchain(11)
}
buildSrc/src/main/groovy/my-java-library.gradle
plugins {
    id 'java-library'
    id 'org.jetbrains.kotlin.jvm'
}

repositories {
    mavenCentral()
}

java {
    toolchain.languageVersion.set(JavaLanguageVersion.of(11))
}

tasks.test {
    useJUnitPlatform()
}

kotlin {
    jvmToolchain {
        languageVersion.set(JavaLanguageVersion.of(11))
    }
}

文件my-java-library的名称是我们全新插件的ID，我们现在可以在所有子项目中使用它。

为什么缺少id 'org.jetbrains.kotlin.jvm'的版本？请参见将外部插件应用于预编译的脚本插件。

通过删除所有冗余的构建逻辑并应用我们的约定my-java-library插件，database-logic构建文件变得更加简单

database-logic/build.gradle.kts
plugins {
    id("my-java-library")
}
database-logic/build.gradle
plugins {
    id('my-java-library')
}

此约定插件使我们能够轻松地在所有构建文件中共享通用配置。任何修改都可以在一个地方进行，简化维护。

二进制插件

二进制插件 是 Gradle 中以独立 JAR 文件形式构建的插件，使用构建脚本中的 plugins{} 块应用于项目。

让我们将 GreetingPlugin 移动到一个独立的项目中，以便我们可以发布它并与他人共享。该插件实际上是从 buildSrc 文件夹移动到名为 greeting-plugin 的独立构建中。

您可以从 buildSrc 发布插件，但不建议这样做。准备发布的插件应该在自己的构建中。

greeting-plugin 只是一个 Java 项目，它生成一个包含插件类的 JAR 文件。

将插件打包并发布到存储库的最简单方法是使用 Gradle 插件开发插件。此插件提供了将脚本编译成可以在其他构建中应用的插件所需的必要任务和配置（包括插件元数据）。

以下是用 Gradle 插件开发插件创建的 greeting-plugin 项目的简单构建脚本

build.gradle.kts
plugins {
    `java-gradle-plugin`
}

gradlePlugin {
    plugins {
        create("simplePlugin") {
            id = "org.example.greeting"
            implementationClass = "org.example.GreetingPlugin"
        }
    }
}
build.gradle
plugins {
    id 'java-gradle-plugin'
}

gradlePlugin {
    plugins {
        simplePlugin {
            id = 'org.example.greeting'
            implementationClass = 'org.example.GreetingPlugin'
        }
    }
}

有关发布插件的更多信息，请参阅 发布插件。

项目插件 vs 设置插件 vs 初始化插件

在本节中使用的示例中，插件接受 Project 类型作为类型参数。或者，插件可以接受类型为 Settings 的参数，以在设置脚本中应用，或接受类型为 Gradle 的参数，以在初始化脚本中应用。

这些类型的插件之间的区别在于它们的应用范围

项目插件

项目插件是应用于构建中特定项目的插件。它可以自定义构建逻辑、添加任务和配置项目特定的设置。

设置插件

设置插件是在 settings.gradle 或 settings.gradle.kts 文件中应用的插件。它可以配置应用于整个构建的设置，例如定义构建中包含哪些项目、配置构建脚本存储库以及将通用配置应用于所有项目。

初始化插件

初始化插件是在 init.gradle 或 init.gradle.kts 文件中应用的插件。它可以配置应用于机器上所有 Gradle 构建的全局设置，例如配置 Gradle 版本、设置默认存储库或将通用插件应用于所有构建。