何时使用 gradle.properties 与 settings.gradle？答案

【问题标题】：When to use gradle.properties vs. settings.gradle?何时使用 gradle.properties 与 settings.gradle？
【发布时间】：2018-01-05 09:04:20
【问题描述】：

一个 gradle build 包含三个文件

build.gradle 定义构建配置脚本
gradle.properties
settings.gradle

问题

settings.gradle 和 gradle.properties 有什么区别？
什么时候应该在settings.gradle 中设置设置？ gradle.properties?

【问题讨论】：

标签： java gradle build build-system

【解决方案1】：

一个多模块项目有一个主模块和许多子模块。它有这样的布局：

(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/

子模块也可以位于子文件夹的更深处，但不修改settings.gradle中的代码，它们的名称将包含此类文件夹的名称。

settings.gradle

settings.gradle的主要作用是定义所有包含的子模块，并标记一棵模块树的目录根，因此在多模块项目中只能有一个settings.gradle文件。

rootProject.name = 'project-x'

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

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

build.gradle

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

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

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

gradle.properties

这是可选的，其主要目的是提供启动选项以用于运行 gradle 本身，例如

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

（可以是任何文件夹或文件的名称。）您可以定义额外的自定义 gradle 文件以重用定义，并通过

将它们包含在其他 gradle 文件中

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

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

buildSrc/...

这个文件夹很特别，它本身就像一个单独的 gradle 项目。它是在做任何其他事情之前构建的，并且可以提供在任何其他 gradle 文件中使用的功能。 由于技术原因，IDE 对此文件夹的引用支持比从多个 build.gradle 文件中提取公共代码到单独位置的任何其他方式都要好得多。

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

构建约定/...

当要共享的逻辑很简单（如版本号）时，此元素是可选的，可用作 buildSrc 的替代品，并且不一定会因为更改一个依赖项的一个版本而触发大型项目的完全重建。此目录的名称是任意的，但它需要包含在根 settings.gradle 中，如下所示：includeBuild 'build-conventions'，它的 build.gradle 应该有 plugins {id("groovy-gradle-plugin")}。

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

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

【讨论】：

【解决方案2】：

`settings.gradle`

settings.gradle 文件是一个 Groovy 脚本，就像 build.gradle 文件一样。每个构建中只会执行一个settings.gradle 脚本（与多项目构建中的多个build.gradle 脚本相比）。 settings.gradle 脚本将在任何 build.gradle 脚本之前执行，甚至在 Project 实例创建之前执行。因此，它是针对 Settings 对象进行评估的。使用此Settings 对象，您可以将子项目添加到构建中，从命令行（StartParameter）修改参数，并访问Gradle 对象以注册生命周期处理程序。因此，如果您的设置与构建相关且不一定与项目相关或需要逻辑在可能的子项目被包括在内，请使用settings.gradle。

`gradle.properties`

gradle.properties 文件是一个简单的 Java Properties 文件，它仅通过自动包含在 Project 对象的范围内（即所谓的“项目属性”）而获得特殊作用。这是一个简单的键值存储，只允许字符串值（因此您需要自己拆分列表或数组）。您可以将gradle.properties 文件放到这些位置：

直接在项目目录中（用于项目相关值）
在用户主目录.gradle 中（用于与用户或环境相关的值）

【讨论】：