以下词汇表帮助您理解 Gradle 术语。

A

Artifact

构建产生的文件或目录,例如 JAR、ZIP 分发包或原生可执行文件。

Artifact 通常设计供用户和其他项目使用或消费,或部署到托管系统。在这种情况下,Artifact 是一个单一文件。在项目间依赖的情况下,目录很常见,以避免生成可发布 Artifact 的成本。

B

构建

构建是 Gradle 执行的原子工作单元的聚合。它由项目组成,这些项目包含一组任务

构建通常有 SUCCESS 或 FAILURE 的结果。

您可以使用 gradlegradlew 命令运行构建。

构建扫描

构建扫描是 Gradle 提供的一项服务,用于识别构建问题和构建性能。

构建脚本

一个 build.gradle 脚本。

构建脚本的存在,以及在settings 脚本中的条目(根构建脚本除外,它不需要条目),共同定义了一个 Gradle 模块

C

能力

能力标识一个或多个组件提供的功能。能力的标识使用类似于模块版本坐标的坐标。默认情况下,每个模块版本提供一个与其坐标匹配的能力,例如 com.google:guava:18.0。能力可用于表达一个组件提供多个特征变体,或两个不同的组件实现了相同的功能(因此不能一起使用)。更多详情,请参见关于能力的章节。

组件

模块的任一单一版本。

对于外部库,组件一词指代一个已发布的库版本。

在构建中,组件由插件定义(例如 Java Library 插件),并提供一种简单的方式来定义用于发布的 publication。它们包含artifacts以及详细描述组件变体的相应元数据。例如,默认设置下的 java 组件包含一个 JAR(由 jar 任务生成)以及 Java apiruntime 变体的依赖信息。它还可以定义额外的变体,例如 sourcesJavadoc,以及相应的 artifacts。

组件元数据规则

组件元数据规则是一种在组件从仓库获取后修改其元数据的规则,例如添加缺失信息或纠正错误信息。与解析规则相反,组件元数据规则在解析开始之前应用。组件元数据规则作为构建逻辑的一部分定义,可以通过插件共享。更多信息,请参见关于使用组件元数据规则修复元数据的章节。

配置

配置是按特定目标分组的一组已命名的依赖项。配置提供对底层已解析模块及其 artifacts 的访问。更多信息,请参见关于依赖配置以及可解析和可消费配置的章节。

"configuration" 是一个被重载的术语,在依赖管理之外有不同的含义。
配置阶段

Gradle 构建由两个主要阶段组成:配置阶段(不要与[sub:terminology_configuration] 实例混淆)和执行阶段

配置阶段首先发生,并且是单线程的。

约定插件

一种构建在生态系统插件之上的[sub:terminology_plugin],它将常见的约定应用到使用该插件的构建脚本中。

跨配置

参见跨项目配置

跨项目配置

跨项目配置指代在多项目构建中管理和定制多个子项目。

它允许您在共享的 build.gradle(.kts)settings.gradle.(kts) 文件中定义通用设置、依赖项和任务,这些文件通常位于根项目中。

build.gradle
subprojects {
    apply plugin: 'java'
    repositories {
        mavenCentral()
    }
    dependencies {
        testImplementation 'junit:junit:4.13.2'
    }
}

跨项目配置通常会破坏项目隔离(Project Isolation)和并行项目执行(Parallel Project Execution),因此应尽可能使用约定插件或适当的 API。

build.gradle
gradle.lifecycle.beforeProject {
    repositories {
        mavenCentral()
    }
}

以下跨项目配置的示例应始终避免

subprojectA/build.gradle
tasks.register("customTask") {
    // Avoid this! Directly accessing outputs from another subproject's task
    def outputFile = project(":subprojectB").tasks.named("someTask").get().outputs.files.singleFile
    inputs.file(outputFile)
    doLast {
        println("Processing file from subprojectB: ${outputFile}")
    }
}
subprojectB/build.gradle
tasks.register("someTask") {
    def outputFile = layout.buildDirectory.file("output.txt")
    outputs.file(outputFile)
    doLast {
        outputFile.get().asFile.text = "Output from subprojectB"
        println("Generated output file in subprojectB: ${outputFile.get().asFile}")
    }
}

这使得 subprojectAsubprojectB 紧密耦合,破坏了模块化,并在并行构建或配置缓存期间产生潜在问题。

D

依赖项

依赖项是指向构建、测试或运行模块所需的另一段软件的指针。更多信息,请参见关于声明依赖项的章节。

依赖约束

依赖约束定义了模块需要满足的要求,以使其成为依赖项的有效解析结果。例如,依赖约束可以缩小支持的模块版本集合。依赖约束可用于表达对传递性依赖项的此类要求。更多信息,请参见关于升级和降级传递性依赖项的章节。

E

Eager

许多 Gradle API 有两种形式:eagerlazy。区别在于何时计算或解析值。

Eager 意味着立即。在配置阶段值会立即被评估。这可能导致不必要的工作,尤其是在大型构建中。它更容易出现性能问题。

build.gradle.kts
// Eager: evaluated as soon as the build script runs
val myValue = file("output.txt")
// Lazy: evaluated only when required
val myValue = layout.buildDirectory.file("output.txt")
生态系统插件

负责构建某种语言(例如 Java (javajava-library)、Groovy、Scala、Android、Kotlin 等)的[sub:terminology_plugin]。许多插件由 Gradle 维护,并且是 Gradle 分发版的一部分。

执行阶段

Gradle 构建的第二个主要阶段,执行阶段在配置阶段完成后发生。在这个阶段,所有任务动作都会被执行。

此阶段具有多层次的并行性。

F

特征变体

特征变体是代表组件可单独选择的功能的变体。特征变体由一个或多个能力标识。更多信息,请参见关于建模特征变体和可选依赖项的章节。

G

Gradle 构建

一个 Gradle 构建可以包含一个或多个 Gradle 项目,并且通常使用根目录下的 settings.gradle(.kts) 文件进行配置。

调用时,Gradle 构建根据定义的构建逻辑执行一组任务,通常使用 Gradle Wrapper (./gradlew)。

H

I

增量构建

增量构建仅执行必要的任务。如果我们运行任何源代码,Gradle 会首先检查该源代码是否经过了之前的执行。如果代码有更改,则会执行,但如果没有更改,则会跳过该代码的执行。

初始化脚本

初始化脚本由 Gradle 类型的一个实例支持。

J

K

L

Lazy

许多 Gradle API 有两种形式:eagerlazy。区别在于何时计算或解析值。

Lazy 意味着延迟。值会延迟到实际需要时才计算或解析,通常在执行阶段。这更高效,并支持配置缓存和最新检查等功能。

build.gradle.kts
// Lazy: evaluated only when required
val myValue = layout.buildDirectory.file("output.txt")
// Eager: evaluated as soon as the build script runs
val myValue = file("output.txt")

M

MavenCentral

MavenCentral 是托管 Maven publication 的主要仓库。它由一家名为 Sonatype 的公司运营,是许多生态系统的默认仓库。

还存在许多其他仓库,例如(现已停用的)jcenterGoogle Maven 仓库

模块

随着时间演进的一段软件,例如 Google Guava。每个模块都有一个名称。每个模块发布版最佳地由模块版本表示。为了方便消费,模块可以托管在仓库中。

模块元数据

模块的发布版提供元数据。元数据是更详细描述模块的数据,例如关于 artifacts 位置或所需传递性依赖项的信息。Gradle 提供自己的元数据格式,称为Gradle Module Metadata (.module 文件),但也支持 Maven (.pom) 和 Ivy (ivy.xml) 元数据。更多关于支持的元数据格式的信息,请参见关于理解 Gradle Module Metadata的章节。

模块版本

模块版本代表已发布的模块的一组不同更改。例如,18.0 代表坐标为 com.google:guava:18.0 的模块版本。实际上,模块版本的方案没有限制。时间戳、数字以及像 -GA 这样的特殊后缀都是允许的标识符。最广泛使用的版本控制策略是语义化版本控制

N

O

P

平台

平台是一组旨在一起使用的模块。存在对应于不同用例的不同类别的平台:

  • 模块集:通常是一组作为一个整体一起发布的模块。使用集合中的一个模块通常意味着我们希望对集合中的所有模块使用相同的版本。例如,如果使用 groovy 1.2,也使用 groovy-json 1.2。

  • 运行时环境:一组已知能良好协作的库,例如 Spring Platform,它推荐 Spring 和与 Spring 良好协作的组件的版本。

  • 部署环境:Java 运行时、应用服务器等……​

    此外,Gradle 定义了虚拟平台

    Maven 的 BOM (bill-of-material) 是一个流行的平台,Gradle 支持
插件

Gradle 构建于插件系统之上。Gradle 本身主要由基础设施组成,例如一个复杂的依赖解析引擎,这对于所有项目类型都是通用的。其其余功能来自插件,包括与 Gradle 本身一起分发的“核心”插件、第三方插件以及给定构建中的脚本插件

根据应用上下文的不同,插件有三种类型

  1. 项目插件,实现 Plugin<Project> 接口,应用于构建脚本

  2. settings 插件,实现 Plugin<Settings> 接口,应用于settings 脚本

  3. 初始化 (Gradle) 插件,实现 Plugin<Gradle> 接口,应用于初始化脚本

插件可以以所谓的二进制插件(即,通过显式实现上述特定泛型接口之一)或预编译脚本插件的形式实现。这种区别仅是实现细节。

预编译脚本插件

等同于插件,但其编写方式看起来像构建脚本,预编译脚本插件可以通过应用 groovy-gradle-pluginkotlin-dsl 插件(分别)使用 Groovy 或 Kotlin 编写。

项目

通常被称为“模块”,每个 Gradle 项目都由一个 Project 实例支持,因此得名。

大多数 Gradle 项目由多个项目组成(通常称为“子项目”)。

Publication

关于文件和元数据(应作为一个单一实体发布到仓库供消费者使用)的描述。

一个 publication 有一个名称,并包含一个或多个 artifacts 以及关于这些 artifacts 的信息(元数据)。

Q

R

仓库

仓库托管一组模块,每个模块可以提供一个或多个由模块版本表示的发布版(组件)。仓库可以基于二进制仓库产品(例如 Artifactory 或 Nexus)或文件系统中的目录结构。更多信息,请参见声明仓库

解析规则

解析规则直接影响依赖项的解析行为。解析规则作为构建逻辑的一部分定义。更多信息,请参见关于直接定制依赖项解析的章节。

S

脚本插件

可以应用于其他 Gradle 脚本(包括构建脚本settings 脚本初始化脚本)的 Gradle 脚本。它可以使用 Groovy 或 Kotlin 编写,并通过 apply 方法应用于其他脚本。根据应用脚本的类型,它们由Project 实例、Settings 实例或Gradle 实例支持。

settings 脚本

一个 settings.gradle(.kts) 脚本。settings 脚本有许多职责,但其中最重要的一项是通过 include :project 声明构成构建的项目集合。

T

任务

每个项目由一个或多个任务组成。每个任务都应该是原子的(尽管通常不是),具有输入和输出。Gradle 执行任务来完成其工作。

任务示例包括:编译源代码、创建 artifacts(如 jars 或 apks)、生成 Javadoc、运行静态分析(例如 lint)、删除临时文件或发布到仓库等。

当要求 Gradle 任务运行时,我们可以看到任务的结果。结果将是 EXECUTED, SKIPPED, FAILED, FROM-CACHE, UP-TO-DATE, NO-SOURCE 之一,或空白(表示已执行)。

传递性依赖项

组件的变体可能依赖于其他模块才能正常工作,这就是所谓的传递性依赖项。托管在仓库上的模块发布版可以提供元数据来声明这些传递性依赖项。默认情况下,Gradle 会自动解析传递性依赖项。传递性依赖项的版本选择可以通过声明依赖约束来影响。

U

V

变体(组件的)

每个组件包含一个或多个变体。变体包含一组 artifacts 并定义一组依赖项。它由一组属性能力标识。

Gradle 的依赖解析是变体感知的,在选择组件(即模块的一个版本)后,会选择该组件的一个或多个变体。如果变体选择结果含糊不清,也可能失败,这意味着 Gradle 没有足够的信息来选择多个互斥变体中的一个。在这种情况下,可以通过变体属性提供更多信息。Java 组件通常提供的变体示例有 apiruntime 变体。其他示例包括 JDK8 和 JDK11 变体。更多信息,请参见关于变体选择的章节。

变体属性

属性用于标识和选择变体。一个变体定义了一个或多个属性,例如 org.gradle.usage=java-api, org.gradle.jvm.version=11。当依赖项被解析时,会请求一组属性,Gradle 会在依赖图中为每个组件找到最合适的变体。可以为一个属性实现兼容性(Compatibility)和消歧(Disambiguation)规则,以表达值之间的兼容性(例如,Java 8 与 Java 11 兼容,但如果请求的版本是 11 或更高,则应首选 Java 11)。此类规则通常由插件提供。更多信息,请参见关于变体选择声明属性的章节。

W

X

Y

Z