从Gradle 6.7开始,Gradle用户手册建议不要使用“跨项目配置”功能来配置子项目,而应该避免使用
subprojects
和
allprojects
。
recommends against
另一个灰心丧气的在子项目之间共享构建逻辑的方式是通过
subprojects{}
和
allprojects{}
DSL结构进行跨项目配置。使用交叉配置,可以将构建逻辑注入到子项目中,在查看子项目的构建脚本时并不明显,这使得理解特定子项目的逻辑变得更困难。从长远来看,交叉配置通常会随着越来越多的条件逻辑和更高的维护负担而变得复杂。交叉配置还可能在项目之间引入
配置时间耦合,这可能会阻止像
按需配置这样的优化正常工作。
建议采用
约定插件的方法来定义共同特征。
Gradle 推荐使用其插件系统来组织构建逻辑。插件应该定义子项目的类型。事实上,
Gradle 核心插件 也是以同样的方式进行建模 - 例如,
Java 插件 配置一个通用的 Java 项目,而
Java 库插件 在内部应用
Java 插件 并配置特定于 Java 库的方面。类似地,
应用程序插件 应用并配置
Java 插件 和
分发插件。
您可以通过应用和配置核心和外部插件来组成自定义构建逻辑,并创建定义新项目类型并配置特定于您的项目或组织的约定的自定义插件。对于本节开头的每个示例特征,我们都可以编写一个插件,封装给定类型的子项目的通用逻辑。
我们建议将约定插件的源代码和测试放在项目根目录中的特殊 buildSrc 目录中。有关 buildSrc 的更多信息,请参阅
使用 buildSrc 组织构建逻辑。
在您的情况下,您可以按照Gradle
示例中给出的方法进行操作:
├── buildSrc
│ ├── build.gradle
│ ├── src
│ │ ├── main
│ │ │ └── groovy
│ │ │ ├── source.java-conventions.gradle
"
buildSrc/build.gradle
文件中只包含 groovy-gradle-plugin
:
"
plugins {
id 'groovy-gradle-plugin'
}
"
buildSrc/src/main/groovy/source.java-conventions.gradle
" 包含了 Java 项目的通用逻辑。在您的示例中,您只是应用了 Java 插件,但您还可以添加任何其他 Java 插件的通用性,这些通用性不会与非 Java 项目共享。"
plugins {
id 'groovy-gradle-plugin'
}
每个 Java 项目都将包括约定插件:
plugins {
id 'source.java-conventions'
}
请注意,如果字面上唯一共同点是Java插件,那么这并没有太多的作用;您只是用另一个插件替换了一个插件。但是,一旦您拥有更多的共享构建逻辑,它就开始在跨项目一致性和减少重复代码方面产生回报。