从很早以前我就一直喜欢Gradle构建工具。 它的潜力甚至在1.0版本之前就已经很明显了，那时变化经常被打破。 如今，升级很少会引起意外。 该工具已经成熟并且运行良好。

Gradle包括一个功能强大的依赖项管理系统，该系统可以与Maven和Ivy存储库以及本地文件系统依赖项一起使用。

在使用Gradle的过程中，我开始依赖一种模式来管理要共享的多项目构建中的依赖项。 此模式包含两个关键实践：

1. 集中依赖声明在build.gradle
2. 集中gradle.properties依赖版本声明

两种实践都是将软件开发最佳实践（例如DRY）应用于组成Gradle构建的代码的示例。 让我们更详细地了解它们。

集中依赖声明

在根项目的build.gradle文件中，为整个项目中使用的每个依赖项声明一个新配置 。 在使用依赖项的每个子项目中，声明compile （或testCompile等）配置扩展了依赖项的配置：
根项目build.gradle

subprojects {configurations {commonsIo}dependencies {commonsIo 'commons-io:commons-io:2.5'}
}

子项目build.gradle

configurations {compile.extendsFrom commonsIo
}

通过将所有依赖项声明放在一个位置，我们知道在哪里查找，并防止多个子项目声明具有不同版本的相同依赖项。

此外，各分项工程现在更声明，指明他们只依赖于什么逻辑组件，而不是一个零件怎样从单个的jar文件建立起来的所有细节。 当存在一对一的对应关系时（如在commons IO示例中），这没什么大不了的，但是当使用由多个jar组成的组件（例如Spring框架或Jetty）时，差异就明显了。

集中依赖版本声明

下一步是将根项目的build.gradle文件中的所有版本号替换为根项目的

gradle.properties ：

build.gradle

dependencies {commonsIo "commons-io:commons-io:$commonsIoVersion"
}

gradle.properties

commonsIoVersion=2.5

通过这种做法，您可以将版本号重新用于相关的依赖项。 例如，如果您使用的是Spring框架，则可能要声明对具有相同版本号的spring-mvc和spring-jdbc依赖关系。

这种方法还有一个优点。 升级依赖项意味着更新gradle.properties ，而添加新依赖项则意味着更新build.gradle 。 这使得从提交提要中轻松判断可能进行了哪些类型的更改，从而确定是否需要进行更仔细的检查。

您可以更进一步，将configurations和dependencies块放在单独的文件中，例如， dependencies.gradle 。

超越…

将所有依赖项声明在一个位置是更高级的供应链管理实践的垫脚石。

集中声明的配置很好地概述了产品中使用的所有组件，即所谓的物料清单（BOM）。 您可以使用上述技术，也可以使用Gradle BOM插件 。

通过BOM，使用OWASP DependencyCheck之类的工具可以更轻松地检查所使用的依赖项中是否公开披露了漏洞。 在EMC，针对我们产品报告的大约80％的漏洞是由第三方组件的问题引起的，因此有必要对依赖项进行安全监视。

可靠的BOM还可简化查看许可证及其合规性要求的过程。 如果您买不起BlackDuck Protex之类的工具，您可以用少量的努力自己编写不太高级的东西。

翻译自: https://www.javacodegeeks.com/2016/05/manage-dependencies-gradle-multi-project-build.html