gradle - gradle中依赖管理的共识

Question

我是第一次在一个多模块项目中使用 Gradle，并且想知道对于这样的工作进行依赖管理的正确/最佳方式是否有任何共识。据我所知，有两种方法，第一种方法似乎更被广泛接受。它看起来像:
[对不起，如果这个虚构的项目是蹩脚的! ]

-- MyProject
---- settings.gradle
---- build.gradle
---- coreProject
---- servicesProject
------ servicesSubProject
---- warProject
---- common

按照这种方法，所有管理都在单个 build.gradle 文件中完成(其他外部 .gradle 文件可用于定义各种工件)，并且各个项目依赖项将在其各自的“项目”定义部分中进行管理，例如:

project('servicesProject:servicesSubProject') {
    dependencies {
        compile project(':common')
        compile spring.data
        compile spring.framework.persistence
        compile spring.framework.security
        compile persistence.hibernate.core
        compile persistence.postgresql
    }
}

另一种方法是为每个子项目创建一个 build.gradle 文件(这里子项目的依赖项位于该项目的 build.gradle 文件的依赖项部分):

-- MyProject
---- settings.gradle
---- build.gradle
---- coreProject
------ build.gradle
---- servicesProject
------ build.gradle
------ servicesSubProject
-------- build.gradle
---- warProject
------ build.gradle
---- common
------ build.gradle

正如我所说，从我能够阅读的内容来看，似乎第一种方法比第二种方法使用更广泛。 Spring Framework gradle 文件就是这样设置的。然而，在我全力以赴之前，我想我应该问一下是否有权衡或其他影响我也应该注意。感谢您的任何想法!

Answer 1

每个子项目都有一个单独的构建脚本可能更常见。将一个大脚本分解为多个小脚本是一种自然的方式，这通常是一件好事。也就是说，一些团队更喜欢使用单个构建脚本，而 Gradle 足够灵活以适应这种情况。

如果您使用多个构建脚本，则以它们所属的子项目命名它们是值得的。这可以通过将以下代码添加到 settings.gradle 来实现(代码假设只有一级子项目):

rootProject.children.each { it.buildFileName = it.name + ".gradle" }

PS:尽管依赖声明通常构成子项目构建脚本的很大一部分，但是否使用一个或多个构建脚本的决定并不特定于依赖管理。