简介：
Java构建工具的关键功能之一是依赖关系管理，我们要在自己的项目中使用某个第三方库，并且构建工具将负责在构建生命周期中的正确时间下载它并将其添加到类路径中。
Maven作为构建工具已经存在了很长时间，它稳定并且在Java社区中仍然很受欢迎。
Gradle在很早以前就已经成为Maven的替代品，它严重依赖于Maven依赖项基础结构，但是提供了一种更加灵活的声明依赖项的方法。
什么是范围/配置？
Maven pom.xml文件或Gradle build.gradle文件指定从我们的源代码创建软件工件的必要步骤。例如，此工件可以是JAR文件或WAR文件。
在大多数不平凡的项目中，我们都依赖第三方库和框架。因此，构建工具的另一任务是管理对这些第三方库和框架的依赖关系。
假设我们要在代码中使用SLF4J日志记录库。在Maven pom.xml文件中，我们将声明以下依赖关系：
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.26</version>
<scope>compile</scope>
</dependency>
在Gradle build.gradle文件中，相同的依赖性如下所示：
implementation 'org.slf4j:slf4j-api:1.7.26'
Maven和Gradle都允许定义不同的依赖组。这些依赖项组在Maven中称为“范围”，在Gradle中称为“配置”。
这些依赖项组中的每一个都有不同的特征，并以不同的方式回答以下问题：
在构建生命周期的哪些步骤中将提供依赖关系？可以在编译时使用吗？在运行时？在测试的编译和运行时？
依赖关系是可传递的吗？它会暴露给我们自己项目的消费者，以便他们也可以使用它吗？如果是这样，它**
将泄漏到使用者的编译时间和/或使用者的运行时中吗？最终构建工件中是否包括依赖项？我们自己项目的WAR或JAR文件是否包括依赖项的JAR文件？
在上面的示例中，我们将SLF4J依赖项添加到了Maven compile范围和Gradle implementation配置中，这可以分别视为Maven和Gradle的默认值。
让我们看一下所有这些作用域和配置的语义。
Maven范围
Maven 为Java项目提供了6个作用域。
但是，我们将不讨论system和import范围，因为它们比较奇特。
compile
该compile范围是默认范围，当我们对声明某个依赖项没有特殊要求时，可以使用它。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 编译时间
- 运行
是 是 是 - 测试编译时间
- 测试运行时
注意，compile作用域会泄漏到编译时，从而加剧依赖污染。
provided
我们可以使用provided作用域声明一个最终构建工件中将不包括的依赖项。
例如，如果我们依赖项目中的Servlet API，并且将其部署到已经提供Servlet API的应用程序服务器上，则可以将依赖项添加到provided作用域中。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 编译时间
- 运行 (没有 没有 没有)
- 测试编译时间
- 测试运行时
runtime
我们将runtime范围用于在编译时不需要的依赖项，例如，当我们针对某个API 进行编译时，只需要在运行时实现该API。
一个示例是SLF4J，我们slf4j-api将其包含在compile范围内，并将该API的实现（如slf4j-log4j12或logback-classic）包含到runtime范围内。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 运行 (没有 是 是)
- 测试运行时
test
我们可以将test作用域用于仅在测试中需要且在生产代码中不可用的依赖项。
此范围的依赖项示例是测试框架，例如JUnit，Mockito或AssertJ。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 测试编译时间 （没有 没有 没有）
- 测试运行时
Gradle配置
Gradle具有更多样化的配置集，这是Gradle变得更年轻，更积极开发的结果，因此能够适应更多的用例。
让我们看一下Gradle的Java库插件的标准配置。请注意，我们必须在构建脚本中声明插件才能访问配置：
plugins {
id 'java-library'
}
implementation
该implementation配置应视为默认配置。我们使用它来声明我们不想暴露给使用者的编译时的依赖项。
引入此配置是为了取代不推荐使用的compile配置，以避免使用我们实际上不想公开的依赖项来污染使用者的编译时间。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
编译时间
运行 没有 是 是
测试编译时间
测试运行时
api
我们使用api配置来声明依赖关系，这些依赖关系是我们API的一部分，即对于我们明确希望暴露给使用者的依赖关系。
这是唯一将依赖项暴露给使用者的编译时的标准配置。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 编译时间
- 运行 (是 是 是)
- 测试编译时间
- 测试运行时
compileOnly
通过compileOnly配置，我们可以声明仅在编译时可用的依赖项，而在运行时则不需要。
这种配置的一个示例用例是像Lombok这样的注释处理器，它在编译时修改字节码。编译后不再需要它，因此依赖项在运行时不可用。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 编译时间 (没有 没有 没有)
runtimeOnly
该runtimeOnly配置使我们可以声明在编译时不需要的依赖关系，但将在运行时可用，类似于Maven的runtime范围。
另一个例子是SLF4J，我们slf4j-api在implementation配置中包括该API以及该配置的实现（例如slf4j-log4j12或logback-classic）runtimeOnly。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 运行 (没有 是 是)
testImplementation
与相似implementation，但是声明的依赖项testImplementation 仅在测试的编译和运行期间可用。
我们可以使用它来声明对测试框架（如JUnit或Mockito）的依赖关系，这些依赖关系仅在测试中需要，而在生产代码中不可用。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 测试编译时间 (没有 没有 没有)
- 测试运行时
testCompileOnly
类似compileOnly，但声明的依赖testCompileOnly是测试编译时可用，而不是在运行时。
我想不出一个具体的例子，但是可能有一些类似于Lombok的注释处理器仅与测试有关。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 测试编译时间 （没有 没有 没有）
testRuntimeOnly
类似runtimeOnly，但声明的依赖testRuntimeOnly是测试运行期间只提供，而不是在编译时。
一个示例是声明对JUnit Jupiter Engine的依赖关系，该引擎运行我们的单元测试，但我们不对其进行编译。
有空的时候？ 泄漏到消费者的编译时间？ 泄漏到消费者的运行时？ 包含在工件中吗？
- 测试运行时 （没有 没有 没有）
结合Gradle配置
由于Gradle的配置非常具体，因此有时我们可能希望结合其功能。在这种情况下，我们可以使用多个配置声明一个依赖项。例如，如果我们希望compileOnly在测试编译时也可以使用依赖项，则可以在testCompileOnly配置中另外声明它：
dependencies {
compileOnly 'org.projectlombok:lombok:1.18.8'
testCompileOnly 'org.projectlombok:lombok:1.18.8'
}
要删除重复的声明，我们还可以告诉Gradle我们希望testCompileOnly配置包括配置中的所有内容compileOnly：
configurations {
testCompileOnly.extendsFrom compileOnly
}
dependencies {
compileOnly 'org.projectlombok:lombok:1.18.8'
}
但是，请注意执行此操作，因为每次以这种方式组合两个配置时，在声明依赖项时都会失去灵活性。
Maven Scope与Gradle配置
Maven范围不能完全转换为Gradle配置，因为Gradle配置更精细。但是，这是一张在Maven范围和Gradle配置之间进行转换的表格，其中有一些有关差异的说明：
Maven范围等效摇篮配置compileapi如果依赖关系应该暴露给消费者，implementation如果不是providedcompileOnly（请注意，providedMaven范围在运行时也可用，而compileOnlyGradle配置不可用）runtimeruntimeOnlytesttestImplementation
结论
作为较年轻的构建工具，Gradle在声明依赖项时提供了更大的灵活性。我们可以更好地控制依赖项是否在测试中，运行时或编译时可用。
