Gradle 存储库解析

Dan*_*der 3 gradle

我正在努力将相对较大的代码库重构为较小的 Gradle 构建和/或模块,尝试使用新的 Kotlin DSL 和构建脚本的最佳实践。

我无法从文档中弄清楚的一个相当不成熟的问题是:我应该在哪里集中管理我的存储库声明?不同的结构如何影响所述存储库的分辨率?

详细说明这一点,我可以通过以下方式声明存储库:

  1. 根据以下内容allprojects {},不鼓励在文件内部或文件subprojects {}中进行交叉配置:build.gradle.kts
allprojects {
    repositories {
        ...
    }
}
Run Code Online (Sandbox Code Playgroud)
subprojects {
    repositories {
        ...
    }
}
Run Code Online (Sandbox Code Playgroud)
  1. 使用文件dependencyResolutionManagement {}中的块settings.gradle.kts
dependencyResolutionManagement {
    repositories {
        ...
    }
}
Run Code Online (Sandbox Code Playgroud)
  1. 使用文件pluginManagement {}中的块settings.gradle.kts
pluginManagement {
    repositories {
        ...
    }
}
Run Code Online (Sandbox Code Playgroud)
  1. 使用buildscript {}块:
buildscript {
    repositories {
        ...
    }
}
Run Code Online (Sandbox Code Playgroud)

我知道这些声明以不同的方式影响构建生命周期不同部分的可用存储库。这就是重点。我什么时候应该使用它们中的每一种,或者在某些情况下应该使用其中不止一种?块中声明的存储库是否会dependencyResolutionManagement {}干扰下载插件的存储库(pluginManagement {}块内声明的存储库)?这些存储库是否以任何方式组合或覆盖,或者它们是完全独立的存储库集?

Rol*_*zer 7

一般来说,Gradle 使用存储库有两种不同的用例:依赖项解析和插件解析

对于存储库,您查找依赖项dependencyResolutionManagement是最现代的方法,并且可能是最好的开始方法。它从 Gradle 6.8 开始可用,并且是专门为在一个地方声明您的存储库而创建的。

subprojects/方法allprojects得到的结果基本上相同,不同之处在于这些值将在内存中复制粘贴到所有子项目上。然而,如果您使用本身修改存储库声明的插件,这可能只会产生影响。但我认为在当前的 Gradle 版本中走这条路没有任何优势。

pluginManagement存储buildscript库用于单独的事物,不用于查找应用程序的依赖库。相反,gradle 使用它们来查找用于构建本身的库,即,如果您删除任何不属于 Gradle 核心应用程序的 Gradle 插件,它们将通过这些附加存储库进行解析。

但是,由于它们已预定义为链接到 Gradle 插件门户,因此您可能根本不需要声明它们。如果您的公司有任何仅在内部存储库中可用的构建插件,您可以声明它们。

为了完整性:pluginManagement用于在plugin块中声明的插件,而buildscript用于在buildscript块中导入的库(也可能是插件)