什么时候使用 gradle.properties 和 setings.gradle？

settings.gradle

settings.gradle文件是一个 Groovy 脚本，就像 build.gradle文件一样。每个构建中只执行一个 settings.gradle脚本(与多个项目构建中的多个 build.gradle脚本相比)。settings.gradle脚本将在任何 build.gradle脚本之前甚至在创建 build.gradle2实例之前执行。因此，它是根据 build.gradle3对象计算的。使用这个 Settings对象，您可以将子项目添加到构建中，从命令行(build.gradle4)修改参数，并访问 build.gradle5对象来注册生命周期处理程序。因此，如果您的设置与构建相关，而不一定与项目相关或需要逻辑 build.gradle6，则使用 settings.gradle。

gradle.properties

gradle.properties文件是一个简单的 JavaProperties文件，只有通过自动包含到 Project对象的作用域(即所谓的“项目属性”)才能获得特殊的角色。它是一个简单的键值存储，只允许字符串值(因此您需要自己拆分列表或数组)。您可以将 gradle.properties文件放在以下位置:

• 直接在项目目录中(对于与项目相关的值)
• 在用户 home .gradle目录中(用于与用户或环境相关的值)

一个多模块项目有 一个主舱和许多子模块，它的布局如下:

(root)
+- settings.gradle
+- build.gradle          # optional (commonly present)
+- gradle.properties     # optional
+-- buildSrc/            # optional
|     +- build.gradle
|     +-- src/...
+-- build-conventions/   # optional
|     +- settings.gradle # empty
|     +- build.gradle
|     +-- src/
|           +-- myconvention.gradle
+-- my-gradle-stuff/     # optional
|     +- utils.gradle    # optional
+-- sub-a/
|     +- build.gradle
|     +- src/
+-- sub-b/
+- build.gradle
+- src/

子模块也可以位于子文件夹的更深处，但是不需要修改 setings.gradle 中的代码，它们的名称将包含这些文件夹的名称。

设置，等级

The main role of settings.gradle is to define all included submodules and to mark the directory root of a tree of modules, so you can only have one settings.gradle file in a multi-module project.

rootProject.name = 'project-x'


include 'sub-a', 'sub-b'

设置文件也是用 groovy 编写的，并且可以自定义子模块查找。

建造，分级

每个模块有一个这样的文件，它包含此模块的构建逻辑。

在 主舱的 build.gradle文件中，可以使用 allprojects {}或 subprojects {}为所有其他模块定义设置。

在子模块的 build.gradle文件中，可以使用 compile project(':sub-a')使一个子模块依赖于另一个子模块。

Gradle 房地产公司

This is optional, its main purpose is to provide startup options to use for running gradle itself, e.g.

org.gradle.jvmargs=-Xmx=... -Dfile.encoding=UTF-8 ...
org.gradle.configureondemand=true

这些值可以被文件 USER_HOME/.gradle/gradle.properties覆盖，也可以被 gradle 命令行参数覆盖。还可以使用 systemProp.作为前缀为该文件中的构建设置环境变量。

这个文件中的任何属性都可以在 build.gradle 中使用，因此一些项目还将依赖版本或发布信息放在 gradle.properties中，但这可能是对这个文件的滥用。

My-gradle-stuff/utils.gradle

(文件夹或文件的任何名称都可以。) 您可以定义额外的自定义级别文件来重用定义，并通过以下方式将它们包含在其他级别文件中

apply from: "$rootDir/gradle/utils.gradle"

其他地方放这可能是 src/gradle或 src/build/gradle

buildSrc/...

这个文件夹是特殊的，它本身就像一个独立的分级项目。它是在做任何其他事情之前构建的，并且可以提供在任何其他 gradle 文件中使用的函数。Because of technical reasons, IDE support for references to this folder work much better than any other way of extracting common code from multiple build.gradle files to a separate location.

您可以用 java、 groovy 或 kotlin 定义复杂的自定义构建逻辑，而不必编写和部署插件。这对于对自定义构建代码进行单元测试也很有用，因为您可以进行单元测试。buildSrc中的源文件夹结构可以像任何 java/groovy/kotlin 项目一样进行调整。

构建-约定/..。

This element is optional and used as a replacement for buildSrc when the logic to be shared is simple, like version numbers, and should not necessarily trigger a full rebuild of a large project for just changing one version of one dependency. The name of this directory is arbitrary, it needs however to be included in the root settings.gradle like this: includeBuild 'build-conventions', and it's build.gradle should have plugins {id("groovy-gradle-plugin")}.

这样就可以在 .gradle files中提取构建逻辑，这些逻辑可以简单地包含在其他模块中，比如 plugins {id("myconvention")}。

这也可以与 buildSrc文件夹结合使用。