使用gradle buildSrc进行依赖关系管理

Question

在buildSrc / src / main / groovy / Dependencies.gradle中管理多模块gradle依赖项是否有用？有什么缺点？

举个例子：

buildSrc / SRC /主/常规/ myproject的/ Dependencies.groovy

package myproject

class Dependencies {
    static Map<String, String> versions = [
        junit: '4.12'
    ]
    static Map<String, String> libraries = [
        "junit:junit:${versions.junit}"
    ]
}

子/的build.gradle：

import example.Dependencies

dependencies {
    testCompile Dependencies.libraries
}

结果：

• Pro：IDE（IntelliJ）跳转到定义，支持代码完成
• Pro：如果不更改buildSrc中的文件，执行应该更快
• Pro：在buildScript块中易于使用的版本号
• Pro：必要时可以使用普通的Groovy或gradle api
• Con：location buildSrc / src / main / groovy / myproject / Dependencies.groovy非常偏远，我猜想可以优化buildSrc / src / Dependencies。

其他人怎么想？将更多gradle构建逻辑移动到buildSrc中的groovy文件也可能对其他配置有用。与apply from相比，IDE完全支持跳转到声明，类型和代码完成的主要优势。

我知道这些替代方案：

• 将版本号保留在gradle.properties
中
• 将版本号保存为root build.gradle中的变量，通常位于ext {} block
中
• 使用Spring依赖关系管理插件（可选择使用BOM）
• 每个依赖项（组）使用新配置