直接依赖与依赖约束
一个组件可能有两种不同类型的依赖：
直接依赖是 directly required by the component 。直接依赖项也称为 first level dependency 。例如，如果您的项目源代码需要使用 Guava，则应将 Guava 声明为 direct dependency 。
传递依赖是你的组件需要的依赖，但只是因为另一个依赖需要它们。
依赖管理问题与 transitive dependencies 有关是很常见的。开发人员通常会通过添加 direct dependencies 错误地修复传递依赖性问题。为了避免这种情况，Gradle 提供了 dependency constraints 的概念。
添加对传递依赖的约束
依赖约束允许您定义构建脚本中声明的依赖项和传递依赖项的版本或版本范围。它是表达应应用于配置的所有依赖项的约束的首选方法。当 Gradle 尝试解析对模块版本的依赖时，所有 带有版本的依赖声明 、所有传递依赖和该模块的所有依赖约束都会被考虑在内。选择符合所有条件的最高版本。如果找不到这样的版本，Gradle 将失败并显示冲突声明的错误。如果发生这种情况，您可以调整依赖项或依赖项约束声明，或者根据需要对传递依赖项进行其他调整。与依赖声明类似，依赖约束声明是受配置范围限制，因此可以为构建的部分选择性地定义。如果依赖约束影响了解析结果，任何类型的 依赖解析规则 仍然可以在之后应用。
KotlinGroovydependencies {
implementation("org.apache.httpcomponents:httpclient")
constraints {
implementation("org.apache.httpcomponents:httpclient:4.5.3") {
because("previous versions have a bug impacting this application")
}
implementation("commons-codec:commons-codec:1.11") {
because("version 1.9 pulled from httpclient has bugs affecting this application")
}
}
}在该示例中，依赖项声明中省略了所有版本。相反，版本是在约束块中定义的。 commons-codec:1.11 的版本定义仅在将 commons-codec 作为传递依赖项引入时才会考虑，因为 commons-codec 未在项目中定义为依赖项。否则，约束无效。依赖约束也可以定义 富版本约束 并支持 严格版本 来执行一个版本，即使它与传递依赖定义的版本相矛盾（例如，如果版本需要降级）。
|
依赖约束仅在使用 Gradle 模块元数据 时发布。这意味着目前它们仅在 Gradle 用于发布和消费时才得到完全支持（即当使用 Maven 或 Ivy 消费模块时它们会“丢失”）。 |
依赖约束本身也可以传递添加。