将您的构建从 Gradle 6.x 升级到 7.0
本章提供您将 Gradle 6.x 构建迁移到 Gradle 7.0 所需的信息。要从 Gradle 5.x 或更早版本迁移,请先完成较旧的迁移指南。
我们建议所有用户执行以下步骤
-
尝试运行
gradle help --scan
并查看生成的构建扫描的弃用视图。这样您就可以看到任何适用于您的构建的弃用警告。
或者,您可以运行
gradle help --warning-mode=all
以在控制台中查看弃用信息,但它可能不会报告那么多详细信息。 -
更新您的插件。
某些插件会因这个新版本的 Gradle 而崩溃,例如,因为它们使用了已被删除或更改的内部 API。上一步将通过在插件尝试使用已弃用的 API 部分时发出弃用警告,帮助您识别潜在的问题。
-
运行
gradle wrapper --gradle-version 7.0
以将项目更新到 7.0。 -
尝试运行项目并使用问题排查指南调试任何错误。
从 6.9 及更早版本升级
IDE 集成中的更改
IDEA 模型中的更改
IdeaContentRoot
接口中移除了 getGeneratedSourceDirectories()
和 getGeneratedTestDirectories()
方法。客户端应将这些调用替换为 getSourceDirectories()
和 getTestDirectories()
,并在返回的实例上使用 isGenerated()
方法。
依赖锁定现在默认为每个项目单个文件
依赖锁文件的格式已更改,因此每个项目只有一个文件,而不是每个配置每个项目一个文件。此更改仅影响写入锁文件。 Gradle 仍然能够加载以旧格式保存的锁定状态。
前往文档,了解如何迁移到新格式。迁移可以按配置执行,不必一步完成。 Gradle 会在将旧锁文件迁移到新文件格式时自动清理它们。
Gradle 模块元数据现在默认是可重现的
默认情况下,buildId
字段不会被填充,以确保在没有构建输入更改时,生成的元数据文件保持不变。如果用户希望将此唯一标识符作为生成的元数据的一部分,他们仍然可以选择加入,请参阅文档。
jcenter()
便利方法现在已弃用
JFrog 宣布 JCenter 仓库将于 2021 年 2 月停止服务。许多 Gradle 构建依赖 JCenter 获取项目依赖项。
没有新的软件包或版本发布到 JCenter,但 JFrog 表示他们将无限期地保持 JCenter 以只读状态运行。我们建议您考虑使用 mavenCentral()
、google()
或私有 maven
仓库代替。
当 jcenter()
用作仓库时,Gradle 会发出弃用警告,并且此方法计划在 Gradle 8.0 中删除。
潜在的破坏性更改
捆绑的 Gradle 依赖项的更新
-
Kotlin 已更新至 Kotlin 1.4.31。
-
Groovy 已更新至 Groovy 3.0.7。
Groovy 和 Groovy DSL 的更改
由于 Groovy 更新到了下一个主要版本,升级到 Gradle 7.0 时,您可能会遇到一些小问题。
新版本的 Groovy 具有更严格的解析器,无法编译可能在以前的 Groovy 版本中被接受的代码。如果您遇到语法错误,请查看Groovy 问题跟踪器和Groovy 3 发布亮点。
一些非常具体的回归已在 Groovy 的下一个次要版本中修复。
Groovy 模块化
Gradle 不再嵌入 groovy-all
的副本,该副本将所有 Groovy 模块捆绑到一个 jar 中——Gradle 发行版中仅分发最重要的模块。
localGroovy()
依赖项将包含以下 Groovy 模块
-
groovy
-
groovy-ant
-
groovy-astbuilder
-
groovy-console
-
groovy-datetime
-
groovy-dateutil
-
groovy-groovydoc
-
groovy-json
-
groovy-nio
-
groovy-sql
-
groovy-templates
-
groovy-test
-
groovy-xml
但是以下 Groovy 模块不包含在内
-
groovy-cli-picocli
-
groovy-docgenerator
-
groovy-groovysh
-
groovy-jmx
-
groovy-jsr223
-
groovy-macro
-
groovy-servlet
-
groovy-swing
-
groovy-test-junit5
-
groovy-testng
您可以像将其他外部依赖项一样将这些依赖项拉入您的构建中。
使用 Groovy 3 构建 Gradle 插件
使用 Gradle 7.0 构建的插件在使用 gradleApi()
或 localGroovy()
时,其类路径上将包含 Groovy 3。
如果您使用 Spock 来测试您的插件,您将需要使用 Spock 2.x。 Spock 1.x 和 Groovy 3 没有兼容版本。 |
dependencies {
// Ensure you use the Groovy 3.x variant
testImplementation('org.spockframework:spock-core:2.0-groovy-3.0') {
exclude group: 'org.codehaus.groovy'
}
}
// Spock 2 is based on JUnit Platform which needs to be enabled explicitly.
tasks.withType(Test).configureEach {
useJUnitPlatform()
}
性能
根据子项目和 Groovy DSL 构建脚本的数量,您可能会注意到首次编译构建脚本或更改构建脚本的类路径时,性能会下降。 这是由于 Groovy 3 解析器的性能较慢,但 Groovy 团队已经意识到这个问题,并正在努力缓解性能下降。
总的来说,我们也在研究如何提高 Groovy DSL 和 Kotlin DSL 构建脚本的编译性能。
遇到“在 DefaultDependencyHandler 上找不到参数 Y 的方法 X”
虽然以下错误最初看起来像编译错误,但实际上是由于特定的 Configuration
已被删除。 请参阅删除 compile
和 runtime
配置了解更多详细信息。
Could not find method testCompile() for arguments [DefaultExternalModuleDependency{group='org.junit', name='junit-bom', version='5.7.0', configuration='default'}] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
默认工具集成版本的更新
-
PMD 已更新至 PMD 6.31.0。
-
Groovy 和 GroovyDoc 已更新至 Groovy 3.0.7。
删除 compile
和 runtime
配置
自 Gradle 诞生以来,它提供了 compile
和 runtime
配置来声明依赖项。 然而,这些配置不支持对依赖项进行细粒度的作用域划分。 因此,Gradle 3.4 中引入了更好的替代方案
-
implementation
配置应用于声明库的实现细节的依赖项:它们在编译时对库的使用者不可见。 -
api
配置(仅当您应用java-library
插件时可用)应用于声明作为库 API 一部分且需要在编译时向使用者公开的依赖项。
在 Gradle 7 中,compile
和 runtime
配置都已删除。 因此,您必须迁移到上面的 implementation
和 api
配置。 如果您仍然为 Java 库使用 java
插件,则需要改为应用 java-library
插件。
已删除的配置 | 新的配置 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
您可以在Java Library 插件文档中找到有关新配置的优势以及使用哪个配置来代替 compile
和 runtime
的更多详细信息。
当使用 Groovy DSL 时,您需要注意处理已删除的配置时出现的特定升级问题。
如果您创建的自定义配置扩展了已删除的配置之一,Gradle 可能会静默创建不存在的配置。
这看起来像这样
configurations {
// This silently creates a configuration called "runtime"
myConf extendsFrom runtime
}
您的自定义配置的依赖解析结果可能与 Gradle 6.x 或更早版本不同。 您可能会注意到缺少依赖项或工件。
ProjectBuilder
的临时项目文件位置
ProjectBuilder
API 用于在单元测试中检查 Gradle 构建。 此 API 过去在系统临时目录(由 java.io.tmpdir
定义)下创建临时项目文件。
该 API 现在在 Test
任务的临时目录下创建临时项目文件。 此路径通常位于项目构建目录下。 当测试期望特定的文件路径时,这可能会导致测试失败。
如果测试使用 ProjectBuilder.withProjectDir(…)
,则不受影响。
TestKit 测试的临时文件位置
使用 TestKit API 的测试过去在系统临时目录(由 java.io.tmpdir
定义)下创建临时文件。 这些文件用于存储 Gradle 发行版的副本或另一个仅用于测试的 Gradle 用户主目录。
TestKit 测试现在将在 Test
任务的临时目录下创建临时文件。 此路径通常位于项目构建目录下。 当测试期望特定的文件路径时,这可能会导致测试失败。
如果测试使用 GradleRunner.withTestKitDir(…)
,则不受影响。
Windows 上 TestKit 的文件系统监视
Windows 上的文件系统监视实现会向根项目目录添加锁,以便监视更改。 当您尝试在使用 TestKit 运行构建后删除根项目目录时,这可能会导致错误。 例如,将 TestKit 与 JUnit 的 @TempDir
扩展或 TemporaryFolder
规则一起使用的测试可能会遇到此问题。 为了避免这些文件锁的问题,TestKit
禁用了通过 GradleRunner
在 Windows 上执行的构建的文件系统监视。 如果您想覆盖默认行为,您可以通过将 --watch-fs
传递给 GradleRunner.withArguments()
来启用文件系统监视。
移除 uploadArchives
任务
uploadArchives
任务与旧的 Ivy 或 Maven 发布机制结合使用。 它已在 Gradle 7 中移除。 您应该迁移到 maven-publish
或 ivy-publish
插件。
有关在 Maven 仓库上发布的更多信息,请参阅 Maven Publish 插件的文档。 有关在 Ivy 仓库上发布的更多信息,请参阅 Ivy Publish 插件的文档。
依赖版本排序中的更改
在依赖版本排序的上下文中,-SNAPSHOT
版本现在被认为紧靠最终版本之前,但在任何 -RC
版本之后。 更多特殊的版本后缀也被考虑在内。 这使 Gradle 算法更接近 Maven 算法,用于众所周知的版本后缀。
查看 文档,了解 Gradle 应用的所有规则。
移除 Play Framework 插件
已弃用的 Play 插件已被移除。 一个外部替代品,Play Framework 插件,可从插件门户获得。
移除已弃用的 JVM 插件
以下未维护的替代 JVM 插件已被移除:java-lang
、scala-lang
、junit-test-suite
、jvm-component
、jvm-resources
。
请改用稳定的 Java Library 和 Scala 插件。
移除实验性的 JavaScript 插件
以下用于实验性 JavaScript 集成的插件现在已从发行版中移除:coffeescript-base
、envjs
、javascript-base
、jshint
、rhino
。
如果您使用了这些插件,尽管它们具有实验性质,您可能会在插件门户中找到合适的替代品。
配置 Ivy 仓库的布局
采用配置块的 layout
方法已被移除,并被 patternLayout 替换。
在没有 Settings 文件的情况下执行 Gradle 构建现在是一个错误
Gradle 构建由其 settings.gradle(.kts)
文件定义,该文件位于当前目录或父目录中。 如果没有 Settings 文件,Gradle 构建是未定义的,并且 Gradle 在尝试执行任务时会产生错误。
要修复此错误,请为构建创建一个 settings.gradle(.kts)
文件。
此规则的例外情况是使用 init
任务调用 Gradle 或使用诊断命令行标志,例如 --version
。
在项目评估后调用 Project.afterEvaluate() 现在是一个错误
Gradle 6.x 警告用户关于错误的行为,并在这种情况下忽略目标操作。 从 7.0 开始,相同的情况将产生错误。 插件和构建脚本应进行调整,以便仅在配置时调用 afterEvaluate
。 如果您有这样的构建失败,并且相关的 afterEvaluate
语句在您的构建源中声明,那么您可以直接删除它。 如果 afterEvaluate
在插件中声明,则将问题报告给插件维护者。
在值最终确定后修改文件集合现在是一个错误
在计算存储值后,在 ConfigurableFileCollection
上调用任何 mutator 方法(即 clear()
、add()
、remove()
等)都会抛出异常。 用户和插件作者应调整其代码,以便对 ConfigurableFileCollection
的所有配置都在配置时发生,在读取值之前。
移除 ProjectLayout#configurableFiles
请改用 ObjectFactory#fileCollection()
。
移除 BasePluginConvention.libsDir
和 BasePluginConvention.distsDir
请改用 libsDirectory
和 distsDirectory
属性。
移除 UnableToDeleteFileException
现有用法应替换为 RuntimeException
。
Checkstyle 和 PMD 插件中移除的属性
-
configDir
getter 和 setter 已从 Checkstyle 任务和扩展中移除。 请改用configDirectory
属性。 -
rulePriority
getter 和 setter 已从 Pmd 任务和扩展中移除。 请改用rulesMinimumPriority
属性。
移除 distribution
插件中的 baseName
属性
getBaseName()
和 setBaseName()
方法已从 Distribution
类中移除。 客户端应将用法替换为 distributionBaseName
属性。
使用 AbstractTask
在 Gradle 6.5 中,注册类型为 AbstractTask
或类型扩展 AbstractTask
的任务已被弃用,现在在 Gradle 7.0 中是一个错误。 您可以使用 DefaultTask 代替。
移除 BuildListener.buildStarted(Gradle)
BuildListener.buildStarted(Gradle)
在 Gradle 6.0 中已弃用,现在在 Gradle 7.0 中已移除。 请改用 BuildListener.beforeSettings(Settings)。
移除未使用的 StartParameter
API
以下 API 自 Gradle 5.0 以来已无法通过命令行选项使用,现在已被移除:StartParameter.useEmptySettings()
、StartParameter.isUseEmptySettings()
、StartParameter.setSearchUpwards(boolean)
和 StartParameter.isSearchUpwards()
。
移除在“master”目录中搜索 Settings 文件
Gradle 不再支持在兄弟目录中名为 master
的目录中发现 Settings 文件。 如果您的构建仍然使用此已弃用的功能,请考虑重构构建以使根目录与项目层次结构的物理根目录匹配。 您可以在用户手册中找到有关如何构建 Gradle 构建的更多信息。 或者,您仍然可以通过仅从 master
目录调用构建,并使用任务的完全限定路径来运行此类构建中的任务。
移除 ValidateTaskProperties
ValidateTaskProperties
任务已被移除,并被 ValidatePlugins 任务取代。
移除 ImmutableFileCollection
ImmutableFileCollection
类型已被移除。 请改用工厂方法。 可以通过 Project.layout 获得项目布局的句柄。
移除 ComponentSelectionReason.getDescription
方法 ComponentSelectionReason.getDescription
已被移除。 它被 ComponentSelectionReason.getDescriptions
取代,后者返回一个 ComponentSelectionDescriptor
列表,每个描述符都有一个 getDescription
。
移除域对象集合构造函数
以下已弃用的构造函数已被移除
-
DefaultNamedDomainObjectList(Class, Instantiator, Namer)
-
DefaultNamedDomainObjectSet(Class, Instantiator)
-
DefaultPolymorphicDomainObjectContainer(Class, Instantiator)
-
FactoryNamedDomainObjectContainer(Class, Instantiator, NamedDomainObjectFactory)
移除任意本地缓存配置
本地构建缓存配置现在需要通过 BuildCacheConfiguration.local() 完成。
移除 DefaultVersionSelectorScheme 构造函数
此内部 API 在插件中使用,其中包括 Nebula 插件,并在 Gradle 5.x 时间线中被弃用,现在已被移除。 最新的插件版本不应再引用它。
在 checkstyle
插件上设置 config_loc
配置属性现在是一个错误
checkstyle
插件现在会因以下配置而失败
checkstyle {
configProperties['config_loc'] = file("path/to/checkstyle-config-dir")
}
构建应使用 checkstyle
块声明 checkstyle 配置
checkstyle {
configDirectory = file("path/to/checkstyle-config-dir")
}
在生产者完成之前查询 Provider 的映射值现在是一个错误
Gradle 6.x 警告用户关于错误的行为,然后返回可能不正确的 Provider 值。 从 7.0 开始,相同的情况将产生错误。 插件和构建脚本应进行调整,以便在任务完成后查询 Provider 的映射值,例如任务输出属性。
任务验证问题现在是错误
Gradle 6.0 开始警告任务定义的问题(例如,错误定义的输入或输出)。 对于 Gradle 7.0,这些警告现在是错误,并将导致构建失败。
当本地项目存在严格版本冲突时,行为发生更改
之前的 Gradle 版本在特定配置中的冲突解决方面存在不一致的行为: - 您的项目声明了对已发布模块的严格依赖(例如,com.mycompany:some-module:1.2!!
,其中 1.2!!
是对 1.2 的严格依赖的简写表示法) - 您的构建实际上提供了更高版本的 com.mycompany:some-module
之前的 Gradle 版本会成功,尽管存在严格约束,但仍选择项目依赖项。 从 Gradle 7 开始,这将触发依赖解析失败。
有关更多上下文,请参阅 此问题。
弃用
任务之间缺少依赖关系
如果一个任务在一个位置生成输出,而另一个任务通过将其作为输入引用来使用该位置,而使用者任务不依赖于生产者任务,则此行为已被弃用。解决此问题的方法是从消费者添加到生产者的依赖。
重复策略
当复制操作(或任何使用 org.gradle.api.file.CopySpec
的操作)遇到重复条目,并且未设置重复策略时,Gradle 7 现在会失败。请查看 CopySpec 文档 以了解详细信息。
从 6.8 及更早版本升级
没有从 6.8 到 6.9 的升级说明,因为 6.9 仅包含错误修复。
从 6.7 及更早版本升级
潜在的破坏性更改
Toolchain API 现在标记为 @NonNull
org.gradle.jvm.toolchain
中支持 Java Toolchain 功能的 API 现在标记为 @NonNull
。
这可能会影响 Kotlin 使用者,因为 API 的返回类型不再可为空。
默认工具集成版本更新
-
JaCoCo 已更新至 0.8.6。
-
Checkstyle 已更新至 Checkstyle 8.37。
-
CodeNarc 已更新至 CodeNarc 2.0.0。
捆绑的 Gradle 依赖项更新
-
Kotlin 已更新至 Kotlin 1.4.20。请注意,Gradle 脚本仍在使用 Kotlin 1.3 语言。
-
Apache Ant 已更新至 1.10.9 以修复 CVE-2020-11979
导入到 Eclipse 的项目现在包含自定义源集类路径
以前,Eclipse 导入的项目仅包含 main 和 test 源集的依赖项。自定义源集的编译和运行时类路径被忽略。
自 Gradle 6.8 起,导入到 Eclipse 的项目包含构建定义的每个源集的编译和运行时类路径。
SourceTask 不再对空目录敏感
以前,在 SourceTask
中声明的源的最新检查和构建缓存键计算期间,会考虑空目录。这意味着包含空目录的源树和不包含空目录的另一个相同的源树将被视为不同的源,即使任务将产生相同的输出。在 Gradle 6.8 中,SourceTask
现在在执行最新检查和构建缓存键计算期间忽略空目录。在绝大多数情况下,这是期望的行为,但是任务可能扩展 SourceTask
,但也可能在源中存在空目录时产生不同的输出。对于关注此问题的任务,您可以公开一个单独的属性,而无需 @IgnoreEmptyDirectories
注释,以便捕获这些更改
@InputFiles
@SkipWhenEmpty
@PathSensitive(PathSensitivity.ABSOLUTE)
public FileTree getSourcesWithEmptyDirectories() {
return super.getSource()
}
发布更改
发布对强制平台具有依赖关系的组件现在会触发验证错误,从而防止意外发布错误的元数据:强制平台用例应仅限于应用程序,而不是可以从另一个库或应用程序中使用的内容。
如果由于某种原因,您仍然希望发布对强制平台具有依赖关系的组件,则可以按照 文档禁用验证。
在执行阶段更改默认排除项
Gradle 的文件树为了方便起见应用了一些默认排除模式——实际上与 Ant 中的默认值相同。有关更多信息,请参见用户手册。有时,Ant 的默认排除项会带来问题,例如,当您想在存档文件中包含 .gitignore
时。
在执行阶段更改 Gradle 的默认排除项可能会导致最新检查的正确性问题。因此,仅允许在设置脚本中更改 Gradle 的默认排除项,有关示例,请参见 用户手册。
弃用
引用包含构建中的任务
直接引用包含构建中的任务在 mustRunAfter
、shouldRunAfter
和 finalizedBy
任务方法中已被弃用。使用 mustRunAfter
和 shouldRunAfter
的任务排序以及由 finalizedBy
指定的终结器应用于构建内的任务排序。如果您碰巧使用上述方法定义了跨构建任务排序,请考虑重构此类构建并将它们彼此解耦。
在“master”目录中搜索设置文件
当您的构建依赖于在同级目录中名为 master
的目录中查找设置文件时,Gradle 将发出弃用警告。
如果您的构建使用此功能,请考虑重构构建以使根目录与项目层次结构的物理根匹配。
或者,您仍然可以通过仅从 master
目录调用构建来运行此类构建中的任务,方法是使用任务的完全限定路径。
使用方法 NamedDomainObjectContainer<T>.invoke(kotlin.Function1)
Gradle Kotlin DSL 扩展已更改为优先使用 Gradle 的 Action<T>
类型,而不是 Kotlin 函数类型。
虽然此更改对于 Kotlin 客户端应该是透明的,但是调用 Kotlin DSL 扩展的 Java 客户端需要更新为使用 Action<T>
API。
从 6.6 及更早版本升级
潜在的破坏性更改
buildSrc 现在可以从根目录看到包含的构建
以前,buildSrc
的构建方式使其忽略了来自根构建的包含构建。
自 Gradle 6.7 起,buildSrc
可以看到来自根构建的任何包含构建。这可能会导致从 buildSrc
中的包含构建中替换依赖项。如果 buildSrc
需要包含构建,这也可能会更改某些构建的执行顺序。
默认工具集成版本更新
-
PMD 已更新至 PMD 6.26.0。
-
Checkstyle 已更新至 Checkstyle 8.35。
-
CodeNarc 已更新至 CodeNarc 1.6.1。
弃用
在执行阶段更改默认排除项
Gradle 的文件树为了方便起见应用了一些默认排除模式——实际上与 Ant 中的默认值相同。有关更多信息,请参见用户手册。有时,Ant 的默认排除项会带来问题,例如,当您想在存档文件中包含 .gitignore
时。
在执行阶段更改 Gradle 的默认排除项可能会导致最新检查的正确性问题,并且已被弃用。仅允许在设置脚本中更改 Gradle 的默认排除项,有关示例,请参见 用户手册。
直接使用 Configuration 作为依赖项
Gradle 允许直接使用 Configuration
的实例作为依赖项
dependencies {
implementation(configurations.myConfiguration)
}
此行为现在已被弃用,因为它令人困惑:人们可能期望首先解析“依赖配置”,并将解析结果作为依赖项添加到包含配置中,但事实并非如此。弃用版本可以用实际行为(即配置继承)代替
configurations.implementation.extendsFrom(configurations.myConfiguration)
从 6.5 及更早版本升级
潜在的破坏性更改
捆绑的 Gradle 依赖项更新
-
Ant 已更新至 1.10.8。
-
Groovy 已更新至 Groovy 2.5.12。
依赖项替换和变体感知依赖项解析
通过该更改,围绕具有更丰富选择器的依赖项(例如平台依赖项)的现有替换将不再像以前那样工作。必须在目标选择器中定义变体感知部分。
如果您
-
依赖于平台,例如
implementation platform("org:platform:1.0")
-
或 如果您在依赖项上指定属性,
-
并且 您在这些依赖项上使用 解析规则。
如果您受到影响,请参阅 文档以解决问题。
弃用
Gradle 6.6 中没有进行弃用。
从 6.4 及更早版本升级
潜在的破坏性更改
捆绑的 Gradle 依赖项更新
-
Kotlin 已更新至 Kotlin 1.3.72。
-
Groovy 已更新至 Groovy 2.5.11。
默认工具集成版本更新
-
PMD 已更新至 PMD 6.23.0。
弃用
内部类 AbstractTask 已被弃用
AbstractTask
是一个内部类,在公共 API 上可见,作为公共类型 DefaultTask
的超类。AbstractTask
将在 Gradle 7.0 中删除,以下内容在 Gradle 6.5 中已弃用
-
注册类型为
AbstractTask
或TaskInternal
的任务。您可以从任务注册中删除任务类型,Gradle 将改用DefaultTask
。 -
注册类型为
AbstractTask
的子类但不是DefaultTask
的子类的任务。您可以将任务类型更改为扩展DefaultTask
。 -
从插件代码或构建脚本中使用类
AbstractTask
。您可以更改代码以改用DefaultTask
。
从 6.3 及更早版本升级
潜在的破坏性更改
PMD 插件默认期望 PMD 6.0.0 或更高版本
Gradle 6.4 默认启用增量分析。增量分析仅在 PMD 6.0.0 或更高版本中可用。如果要使用旧版本的 PMD,则需要禁用增量分析
pmd {
incrementalAnalysis = false
}
依赖项锁定中的更改
在 Gradle 6.4 中,依赖项锁定 LockMode
的孵化 API 已更改。该值现在通过 Property<LockMode>
而不是直接 setter 设置。这意味着对于 Kotlin DSL,必须更新设置值的表示法
dependencyLocking {
lockMode.set(LockMode.STRICT)
}
Groovy DSL 的用户不应受到影响,因为表示法 lockMode = LockMode.STRICT
仍然有效。
已发布元数据中的 Java 版本
如果使用 Gradle Module Metadata 发布 Java 库,则它支持的 Java 版本信息将编码在 org.gradle.jvm.version
属性中。默认情况下,此属性设置为您在 java.targetCompatibility
中配置的内容。如果未配置,则将其设置为运行 Gradle 的当前 Java 版本。更改特定编译任务的版本,例如 javaCompile.targetCompatibility
对该属性没有影响,如果未手动调整该属性,则会导致错误的信息。现在已修复此问题,并且该属性默认为与从中构建已发布 jar 的源关联的编译任务的设置。
具有自定义布局的 Ivy 仓库
从 6.0 到 6.3.x 版本的 Gradle 在 Ivy 仓库上发布时可能会生成错误的 Gradle Module Metadata,该仓库具有自定义仓库布局。从 6.4 开始,如果 Gradle 检测到您正在使用自定义仓库布局,则不再发布 Gradle Module Metadata。
新属性可能会遮蔽构建脚本中的变量
此版本在不同位置引入了一些新属性——mainClass
、mainModule
、modularity
。由于这些是非常通用的名称,因此您很可能在构建脚本中将其中一个用作变量名。然后,新属性可能会以不希望的方式遮蔽您的变量之一,从而导致构建失败,其中访问的是属性而不是具有相同名称的局部变量。您可以通过重命名构建脚本中相应的变量来修复它。
受影响的是 application {}
和 java {}
配置块内部、使用 project.javaexec {}
的 java 执行设置内部以及各种任务配置(JavaExec
、CreateStartScripts
、JavaCompile
、Test
、Javadoc
)内部的配置代码。
捆绑的 Gradle 依赖项更新
-
Kotlin 已更新至 Kotlin 1.3.71。
弃用
Gradle 6.3 和 6.4 之间没有弃用。
从 6.2 及更早版本升级
潜在的破坏性更改
IDEA 中可用的依赖项更少
Gradle 不再将注释处理器类路径作为提供的依赖项包含在 IDEA 中。IDEA 在编译时看到的依赖项与 Gradle 在解析编译类路径(配置名为 compileClasspath
)后看到的依赖项相同。这防止了注释处理器依赖项泄漏到项目的代码中。
捆绑的 Gradle 依赖项更新
-
Kotlin 已更新至 Kotlin 1.3.70。
-
Groovy 已更新至 Groovy 2.5.10。
默认工具集成版本更新
-
PMD 已更新至 PMD 6.21.0。
-
CodeNarc 已更新至 CodeNarc 1.5。
为某些 32 位操作系统删除了富控制台支持
Gradle 6.3 不支持 32 位 Unix 系统和旧 FreeBSD 版本(旧于 FreeBSD 10)的 富控制台。Microsoft Windows 32 位不受影响。
Gradle 将继续在 32 位系统上构建项目,但不再显示富控制台。
弃用
使用 default 和 archives 配置
虽然这些配置将在 Gradle 中保留以实现向后兼容性,但是现在不建议使用它们来声明依赖项或解析依赖项。
解析这些配置从来都不是预期的用例,只是因为在早期的 Gradle 版本中每个配置都是可解析的。对于声明依赖项,请使用您使用的插件提供的配置,例如 Java Library 插件提供的配置。
从 6.1 及更早版本升级
潜在的破坏性更改
编译和运行时类路径现在默认请求库变体
JVM 项目中的类路径现在显式请求 org.gradle.category=library
属性。如果无法使用某个库,这将导致更清晰的错误消息。例如,当库不支持所需的 Java 版本时。实际效果是,现在所有 平台依赖项都必须声明为平台依赖项。以前,当为本地平台或使用 Gradle Module Metadata 发布的平台省略 platform()
关键字时,平台依赖项也可以意外地工作。
来自项目根目录 gradle.properties
的属性泄漏到 buildSrc
和包含的构建中
Gradle 6.2 和 Gradle 6.2.1 中存在一个回归,导致在项目根目录 gradle.properties
文件中设置的 Gradle 属性泄漏到 buildSrc
构建和根目录包含的任何构建中。
如果 buildSrc
构建或包含的构建突然发现来自项目根目录 gradle.properties
文件的属性的意外或不兼容值,则可能导致您的构建开始失败。
该回归已在 Gradle 6.2.2 中修复。
弃用
Gradle 6.1 和 6.2 之间没有弃用。
从 6.0 及更早版本升级
弃用
在任务完成之前查询任务的映射输出属性
在任务完成之前查询映射输出属性的值可能会导致奇怪的构建失败,因为它表明可能会错误地使用过时或不存在的输出。此行为已被弃用,并将发出弃用警告。这将在 Gradle 7.0 中变为错误。
以下示例演示了此问题,其中在 Producer 执行之前解析了 Producer 的输出文件
class Consumer extends DefaultTask {
@Input
final Property<Integer> threadPoolSize = ...
}
class Producer extends DefaultTask {
@OutputFile
final RegularFileProperty outputFile = ...
}
// threadPoolSize is read from the producer's outputFile
consumer.threadPoolSize = producer.outputFile.map { it.text.toInteger() }
// Emits deprecation warning
println("thread pool size = " + consumer.threadPoolSize.get())
如果在 producer
完成之前完成,则查询 consumer.threadPoolSize
的值将产生弃用警告,因为输出文件尚未生成。
已停止使用的方法
以下方法已停止使用,不应再使用。它们将在 Gradle 7.0 中删除。
-
BasePluginConvention.setProject(ProjectInternal)
-
BasePluginConvention.getProject()
-
StartParameter.useEmptySettings()
-
StartParameter.isUseEmptySettings()
替代 JVM 插件(又名“软件模型”)
一组用于 Java 和 Scala 开发的替代插件在 Gradle 2.x 中作为基于“软件模型”的实验引入。这些插件现在已被弃用,最终将被删除。如果您仍在使用这些旧插件之一(java-lang
、scala-lang
、jvm-component
、jvm-resources
、junit-test-suite
),请查阅有关 构建 Java 和 JVM 项目 的文档,以确定哪些稳定的 JVM 插件适合您的项目。
潜在的破坏性更改
ProjectLayout
不再作为服务提供给 worker actions
在 Gradle 6.0 中,ProjectLayout
服务通过服务注入提供给 worker actions。此服务允许可变状态泄漏到 worker action 中,并引入了一种在 worker action 中声明未声明依赖项的方法。
ProjectLayout
已从可用服务中删除。使用 ProjectLayout
的 worker actions 应切换为注入 projectDirectory
或 buildDirectory
作为参数。
捆绑的 Gradle 依赖项更新
-
Kotlin 已更新至 Kotlin 1.3.61。
默认工具集成版本更新
-
Checkstyle 已更新至 Checkstyle 8.27。
-
PMD 已更新至 PMD 6.20.0。
发布 Spring Boot 应用程序
从 Gradle 6.2 开始,Gradle 在上传之前执行健全性检查,以确保您不会上传过时的文件(由另一个构建生成的文件)。这给使用 components.java
组件上传的 Spring Boot 应用程序带来了一个问题
Artifact my-application-0.0.1-SNAPSHOT.jar wasn't produced by this build.
这是因为 Spring Boot 应用程序禁用了主要的 jar
任务,并且该组件期望它存在。由于 bootJar
任务默认使用与主要 jar
任务相同的文件,因此以前版本的 Gradle 会
-
发布过时的
bootJar
工件 -
或者,如果之前未调用
bootJar
任务,则会失败
一种解决方法是告诉 Gradle 要上传的内容。如果要上传 bootJar
,则需要配置传出配置以执行此操作
configurations {
[apiElements, runtimeElements].each {
it.outgoing.artifacts.removeIf { it.buildDependencies.getDependencies(null).contains(jar) }
it.outgoing.artifact(bootJar)
}
}
或者,您可能想要重新启用 jar
任务,并使用不同的分类器添加 bootJar
。
jar {
enabled = true
}
bootJar {
classifier = 'application'
}