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框架gradle文件以这种方式设置。然而，在我全速前进之前，我想我应该问问是否存在权衡或其他影响，我也应该知道。感谢您的任何想法！

Answer 1

我目前正在研究一个约30个gradle子项目的Java项目。现在我们使用这两种方案的方便（至少对我们来说）混合物

/(root) 
- build.gradle 
- subproject_1 
- subproject_2 
- webservices 
-- build.gradle 
-- webservice 1 
-- webservice 2 
- database 
- build.gradle 
-- db-binding1 
-- db-binding2 

我们有一个build.gradle在我们的根项目，定义诸如Maven仓库，插件，编码和这样所有常见的事情。 该文件还包含所有子项目的所有信息，包括所有子项目的依赖关系compile和runtime。我们喜欢将所有外部库定义在一个文件中的想法。

然后 - 由于我们的子项目按技术主题进行了分组，因此我们有定义特定于其子项目（以及仅限于它们）的任务和配置的“内部”文件build.gradle。例如，我们有一个build.gradle定义了webservice绑定的任务，一个用于数据库绑定等等。

你可能会有所不同。如果您的项目比较大，则可能需要为每个子项目配置一个build.gradle。

但是，您以后可以随时改变自己的习惯，而不需要太多努力，并且可以轻松拆分/合并文件。

Answer 2

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

如果使用多个构建脚本，则可以在它们所属的子项目之后命名它们。这可以通过添加以下代码settings.gradle（代码假定只有一个级别的子项目）来实现：

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

PS：虽然依赖声明往往形成一个子项目的构建脚本的一个大的一部分，决定是否使用一个或多个构建脚本并不特定于依赖管理。