我正在努力将相对较大的代码库重构为较小的 Gradle 构建和/或模块,尝试使用新的 Kotlin DSL 和构建脚本的最佳实践。
我无法从文档中弄清楚的一个相当不成熟的问题是:我应该在哪里集中管理我的存储库声明?不同的结构如何影响所述存储库的分辨率?
详细说明这一点,我可以通过以下方式声明存储库:
build.gradle.kts
文件中的allprojects {}
或subprojects {}
内的交叉配置,根据 this 不鼓励这样做:
allprojects {
repositories {
...
}
}
subprojects {
repositories {
...
}
}
- 使用
settings.gradle.kts
文件中的dependencyResolutionManagement {}
block :
dependencyResolutionManagement {
repositories {
...
}
}
- 使用
settings.gradle.kts
文件中的pluginManagement {}
block :
pluginManagement {
repositories {
...
}
}
- 使用
buildscript {}
block :
buildscript {
repositories {
...
}
}
我知道这些声明以不同的方式影响构建生命周期不同部分的可用存储库。这就是重点。我什么时候应该使用它们中的每一种,或者在某些情况下应该使用其中不止一种? dependencyResolutionManagement {}
block 中声明的存储库是否会干扰下载插件的存储库(在 pluginManagement {}
block 内声明的存储库)?这些存储库是否以任何方式组合或覆盖,或者它们是完全独立的存储库集?
最佳答案
一般来说,Gradle 使用存储库有两种不同的用例:依赖项解析和插件解析
对于存储库,您查找依赖项 dependencyResolutionManagement
是最现代的方法,并且可能是最好的开始方法。
它从 Gradle 6.8 开始可用,并且是专门为在一个地方声明您的存储库而创建的。
subprojects
/allprojects
方法可为您提供基本相同的结果,不同之处在于这些值将在内存中复制粘贴到所有子项目上。然而,如果您使用本身修改存储库声明的插件,这可能只会产生影响。但我认为在当前的 Gradle 版本中走这条路没有任何优势。
pluginManagement
和 buildscript
存储库用于单独的事情,不用于查找应用程序的依赖库。
相反,gradle 使用它们来查找用于构建本身的库,即,如果您删除任何不属于 Gradle 核心应用程序的 Gradle 插件,它们将通过这些附加存储库进行解析。
但是,由于它们已预定义为链接到 Gradle 插件门户,因此您可能根本不需要声明它们。如果您的公司有任何仅在内部存储库中可用的构建插件,您可以声明它们。
为了完整性:pluginManagement
用于在 plugin
block 中声明的插件,而 buildscript
用于在 中导入的库buildscript
block (也可能是插件)
关于Gradle 存储库解析,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/73502079/