![](/img/trans.png)
[英]How to determine what goes into settings.gradle vs. bulid.gradle?
[英]When to use gradle.properties vs. settings.gradle?
一个 gradle build 包含三个文件
build.gradle
gradle.properties
settings.gradle
问题
settings.gradle
和gradle.properties
之间有什么区别?settings.gradle
与gradle.properties
?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
目录中(用于用户或环境相关的值)一个多模块项目有一个主模块和许多子模块。 它有这样的布局:
(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
文件。
rootProject.name = 'project-x'
include 'sub-a', 'sub-b'
设置文件也是用groovy写的,可以自定义子模块查找。
每个模块有一个这样的文件,它包含该模块的构建逻辑。
在主模块的build.gradle
文件中,您可以使用allprojects {}
或subprojects {}
来定义所有其他模块的设置。
在子模块的build.gradle
文件中,您可以使用compile project(':sub-a')
使一个子模块依赖于另一个子模块。
这是可选的,它的主要目的是提供用于运行 gradle 本身的启动选项,例如
org.gradle.jvmargs=-Xmx=... -Dfile.encoding=UTF-8 ...
org.gradle.configureondemand=true
这些值可以被文件USER_HOME/.gradle/gradle.properties
覆盖,并被 gradle 命令行参数覆盖。 也可以使用systemProp.
作为前缀。
这个文件中的任何属性都可以在任何 build.gradle 中使用,所以一些项目也会将依赖版本或发布信息放在gradle.properties
中,但这很可能是对这个文件的滥用。
(文件夹或文件的任何名称都是可能的。)您可以定义其他自定义 gradle 文件以重用定义,并将它们包含在其他 gradle 文件中
apply from: "$rootDir/gradle/utils.gradle"
其他放置它的地方可能是src/gradle
或src/build/gradle
这个文件夹比较特殊,它本身就像一个独立的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
文件夹结合使用。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.