Artifact
“Artifact”通常在发布的上下文中用于指定名称具有“分类器”和“扩展名”的文件。Publication 中的两个 artifacts 不能具有相同的分类器和扩展名。
令人困惑的是，当在 Maven 坐标的上下文中使用时，artifactId 指的是上述工件的列表。例如，okhttp artifactId 包含 jar、sources 和 javadocs 工件。
由build生成的文件或目录，如JAR、ZIP发行版或本地可执行文件。
Artifacts通常设计为供用户或其他项目使用，或部署到宿主系统。在这种情况下，Artifact是单个文件。目录在项目间依赖的情况下很常见，以避免产生可发布Artifact的成本。
Publication
单个实体发布到存储库以供使用者使用的文件和元数据的描述。
一个发布对象（出版物）有一个名称和由一个或多个artifacts以及关于这些artifacts的信息（元数据）组成。
Gradle Publication 是一个工件列表，可能还有相关的元数据。大多数时候使用 maven-publish 插件处理 MavenPublications 以 Maven 发布格式发布。
Build
“build” 是 Gradle 执行的原子工作的聚合。构建由一些 project 组成，这些 project 具有一系列 task 。build 通常具有成功或失败的结果。可以使用 gradle 或 gradlew 命令运行 build。
Build script
一个 build.gradle 脚本。build 脚本的存在，以及 settings 脚本中的一个条目（除了不需要条目的根 build 脚本），就是定义 Gradle 模块的原因。
Configuration
Configuration是为特定目标分组在一起的一组命名的依赖项。Configuration提供对底层已解析模块及其Artifacts的访问。
在最基本的级别上，Configuration 是一桶依赖项。大多数人都见过的最常见的配置是 api 和 implementation。了解有关 Configuration 的更多信息的好地方是 java-library 插件的文档。
“configuration” 这个词是 Gradle 世界中最重载的词之一。
虽然对于 Gradle 用户来说，作为依赖项的使用是最常见的，但插件作者也可以以其他方式使用配置：
- 作为 FileCollection 作为任务的输入（例如 runtimeClasspath）。
- 作为稍后发布的传出变体（例如 apiElements）
Configuration phase
Gradle build 由两个主要阶段组成，configuration 阶段（不要与配置实例混淆）和执行阶段。configuration 阶段首先发生并且是单线程的。
Convention plugin
建立在生态系统插件之上的插件，并将通用约定应用于使用该插件的 build script。
Ecosystem plugin
一个 Plugin 负责构建一种语言，例如 Java（java 和 java-library）、Groovy、Scala、Android、Kotlin 等。许多插件由 Gradle 本身维护，并且是 Gradle 发行版的一部分。
Execution phase
Gradle build 的第二个主要阶段，执行阶段发生在配置阶段完成之后。这是执行所有任务操作的地方。此阶段具有多个级别的并行性。
Gradle
Gradle 是由盈利性公司 Gradle, Inc. 开发和维护的开源构建系统。
Init script
init 或初始化脚本由 Gradle 类型的实例支持。
Maven (build tool)
Maven 是类似于 Gradle 的构建工具，但使用基于 XML 的更具声明性的语法。对于发布依赖项，Maven 使用 Maven 发布格式。
Maven (publication format)
Maven 发布格式是大多数 JVM 生态系统用来发布和使用二进制依赖项的格式。每个依赖项都由一个名为“Maven 坐标”的“artifact:root/version/ 上的文件（通过 HTTP 或本地文件系统）来使用这些依赖项. 例如，com.squareup.okhttp3:okhttp:4.9.3 的文件可在 repo.maven.apache.org/maven2/com/…
虽然最初是为 Maven 构建工具制作的，但 Gradle 还支持 Maven 发布格式。为了提供更大的灵活性，Gradle 还引入了 Gradle 模块元数据，以提供比常规 pom 文件更多的依赖关系信息。
MavenCentral
MavenCentral 是托管 Maven 出版物的主要存储库。它由一家名为 Sonatype 的公司运营，是许多生态系统的默认存储库。存在其他存储库，例如（现已不复存在的）jcenter 或 Google Maven 存储库。
Module
Project 的非正式术语，但比正式术语更常见。模块是包含源代码的目录，或多或少独立于多模块（或多项目）项目中的其他模块。
这是 Gradle 世界中其他非常重载的术语之一。
一种随时间发展的软件，例如Google Guava。每个模块都有一个名称。模块的每一个版本都由一个模块版本最佳地表示。为了方便使用，可以将模块托管在存储库中。
Module metadata
Module的发行版提供元数据。元数据是更详细地描述模块的数据，例如有关artifacts的位置或所需可传递依赖项的信息。Gradle提供了自己的元数据格式Gradle Module metadata（.Module file），但也支持Maven（.pom）和Ivy(ivy.xml)元数据。
Module version
模块版本表示已发布模块的一组不同的更改。例如com.google:guava:18.0，18.0表示带有坐标的模块版本。在实践中，模块版本的方案没有限制。时间戳、数字、像-GA这样的特殊后缀都是允许的标识符，最广泛使用的版本控制策略是语义版本控制。每个公司可能都有其模块版本号的规则，就像ipv4一样，有的分为主版本号、次版本号、末版本号等。
Plugin
Gradle 建立在插件系统上。 Gradle 本身主要由基础设施组成，例如所有项目类型通用的复杂依赖解析引擎。它的其余功能来自插件，包括随 Gradle 本身分发的“核心”插件、第三方插件和给定构建中的 script plugins。
根据应用的上下文，共有三种插件：
实现 Plugin<Project> 的项目插件，应用于构建脚本。
实现 Plugin<Settings> 的设置插件，应用于设置脚本。
实现 Plugin<Gradle> 的初始化 (Gradle) 插件，应用于初始化脚本。
插件可以实现为所谓的二进制插件（即，通过显式实现上述特定通用接口之一），或预编译的脚本插件。这种区别仅仅是一个实现细节。
Precompiled script plugin
相当于一个插件，但编写成看起来像一个构建脚本，预编译的脚本插件可以通过分别应用 'groovy-gradle-plugin' 或 kotlin-dsl 插件在 Groovy 或 Kotlin 中编写。
Project
通常被称为“模块”，每个 Gradle 项目都由一个 Project 实例支持，因此得名。最常见的插件类型是 project 插件。大多数 Gradle 项目由许多 project 组成（有时称为“子项目”）。
Script plugin
一个可应用于其他 gradle 脚本的 gradle 脚本，包括构建脚本、设置脚本和初始化脚本。可以用 Groovy 或 Kotlin 编写，并通过 PluginAware.apply 应用于其他脚本。例如，apply from: 'complicated_thing.gradle'。根据它们所应用的脚本类型，它们由 Project 实例、Settings 实例或 Gradle 实例支持。
Settings script
一个 settings.gradle 脚本。设置脚本有很多职责，但最重要的一个是通过 include ':project1' 等来声明作为构建一部分的项目集。
Task
每个项目由一个或多个任务组成。每个任务都应该是原子的（但通常不是），具有输入和输出。 Gradle 执行任务来完成它的工作。任务示例包括：编译源代码、创建工件（例如 jar 或 apk）、生成 Javadoc、运行静态分析（例如 lint）、删除临时文件或发布到存储库等。当要求运行 Gradle 任务时，我们可以看到任务的结果。这将是 EXECUTED、SKIPPED、FAILED、FROM-CACHE、UP-TO-DATE、NO-SOURCE 或空白（表示已执行）之一。
SoftwareComponent
SoftwareComponent 是由 Gradle 构建的工件列表。这是一个相对较新的 API，用于连接传出配置和发布。大多数时候，您将使用已经存在的组件（例如 java 或 android 组件）来配置您的 maven 发布。如果您是插件作者，您很可能会处理 AdhowComponentWithVariants。
Capability
一个功能标识一个或多个组件提供的特性。能力是通过与模块版本使用的坐标类似的坐标来标识的。例如：com.google:guava:18.0。功能可以用来表示一个组件提供了多个特性变量，或者两个不同的组件实现了相同的特性（因此不能一起使用）。
Component
模块的任何单一版本。
对于外部库，Component是指库的一个已发布版本。在构建中，Component由插件（例如Java库插件）定义，并提供了一种简单的方法来定义对象的发布。它们包括Artifact以及详细描述Component变体的适当元数据。例如，默认设置中的java组件由JAR任务生成的JAR以及Java API和运行时变体的依赖信息组成。它还可以定义附加的变体，例如sources和Javadoc，以及相应的Artifacts。
Component metadata rule
组件元数据规则是一种用于在从存储库获取组件元数据后修改该组件的元数据的规则，例如添加丢失的信息或更正错误的信息。与解析规则不同，组件元数据规则是在解析开始之前应用的。组件元数据规则被定义为构建逻辑的一部分，可以通过插件共享。
Dependency
依赖关系是指向构建、测试或运行模块所需的另一个软件的指针。如果没有对应的软件指向，就无法正常构建、测试或运行该模块。
Dependency constraint
依赖约束定义了模块需要满足的需求，以使其成为依赖项的有效解析结果。例如，依赖约束可以缩小支持的模块版本集。依赖性约束可以用来表示这种对可传递依赖性的需求。
Feature Variant
特征变量是表示可以单独选择或不选择的零部件特征的变量。特征变量由一个或多个功能标识。
Platform
平台是一组旨在一起使用的模块。平台有不同的类别，对应不同的用例：
- 模块集：通常是作为一个整体发布的一组模块。使用集合中的一个模块通常意味着我们希望对集合中的所有模块使用相同的版本。例如，如果使用groovy 1.2，也可以使用groovy-json 1.2。
- 运行时环境：一组已知可以很好地协同工作的库。例如，Spring平台，为Spring和与Spring配合良好的组件推荐版本。
- 部署环境：Java运行时、应用服务器等。
此外，Gradle定义了虚拟平台。Maven的BOM（bill-of-material）是Gradle支持的一种流行的平台。
Repository
存储库承载一组模块，每个模块可以提供一个或多个由模块版本指示的版本（组件）。存储库可以基于二进制存储库产品（例如Artifactory或Nexus）或文件系统中的目录结构。
Resolution rule
解析规则直接影响依赖项的解析方式，解析规则被定义为构建逻辑的一部分。
Transitive dependency
组件的变体可以依赖于其他模块来正常工作，即所谓的可传递依赖。存储库中托管的模块版本可以提供元数据来声明这些可传递的依赖关系。默认情况下，Gradle自动解析可传递的依赖项。可传递依赖项的版本选择可能会受到声明依赖项约束的影响。
Variant
每个组件由一个或多个变体组成。变体由一组artifacts组成，并定义一组依赖项。它由一组属性和能力来标识。
Gradle的依赖关系解析是变量感知的，并在选择组件（即模块的一个版本）后选择每个组件的一个或多个变量。如果变量选择结果不明确，也可能失败，这意味着Gradle没有足够的信息来选择多个互斥变量中的一个。在这种情况下，可以通过变量属性提供更多信息。每个Java组件通常提供的变体示例有api和运行时变体。其他的例子是JDK8和JDK11变体。
Variant Attribute
属性用于识别和选择变体，变量定义了一个或多个属性。例如，org.gradle.usage=java-api, org.gradle.jvm.version=11。解决依赖关系时，会请求一组属性，Gradle会为依赖关系图中的每个组件找到最佳拟合变量。可以为表示值之间兼容性的属性实现兼容性和消歧规则（例如，Java 8与Java 11兼容，但如果请求的版本是11或更高版本，则应首选Java 11），这些规则通常由插件提供。
