何时使用 gradle.properties 与 settings.gradle?

2022-08-31 09:13:44

一个 gradle 版本有三个文件

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

问题

  • 和 之间有什么区别?settings.gradlegradle.properties
  • 何时应将设置放入 vs. ?settings.gradlegradle.properties

答案 1

settings.gradle

该文件是一个 Groovy 脚本,就像文件一样。每个生成中将只执行一个脚本(与多项目生成中的多个脚本相比)。该脚本将在任何脚本之前甚至在创建项目实例之前执行。因此,它是针对设置对象计算的。使用此对象,您可以将子项目添加到构建中,从命令行修改参数(StartParameter),以及访问 Gradle 对象以注册生命周期处理程序。因此,如果您的设置与生成相关,而不一定与项目相关,或者在包含可能的子项目之前需要逻辑请使用。settings.gradlebuild.gradlesettings.gradlebuild.gradlesettings.gradlebuild.gradleSettingssettings.gradle

gradle.properties

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

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

答案 2

多模块项目有一个主模块和多个子模块。它具有以下布局:

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

设置文件也是用时髦的,并且可以自定义子模块查找。

build.gradle

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

主模块的文件中,可以使用 或 定义所有其他模块的设置。build.gradleallprojects {}subprojects {}

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

gradle.properties

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

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

这些值可以被文件覆盖,并被 gradle 命令行参数覆盖。此外,还可以使用前缀在此文件中为构建设置环境变量。USER_HOME/.gradle/gradle.propertiessystemProp.

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

my-gradle-stuff/utils.gradle

(文件夹或文件的任何名称都是可能的。您可以定义其他自定义 gradle 文件以重复使用定义,并通过以下方式将它们包含在其他 gradle 文件中

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

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

buildSrc/...

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

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

构建约定/...

此元素是可选的,当要共享的逻辑很简单(如版本号)时,此元素可用作 buildSrc 的替代元素,并且不一定会触发大型项目的完整重新生成,以便仅更改一个依赖项的一个版本。此目录的名称是任意的,但是它需要包含在根设置中.gradle,如下所示:,并且它的build.gradle应该有.includeBuild 'build-conventions'plugins {id("groovy-gradle-plugin")}

然后,这允许提取构建逻辑,可以简单地包含在其他模块中,例如 。.gradle filesplugins {id("myconvention")}

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


推荐