原文网址：gradle--配置文件(init.gradle, settings.gradle等)_IT利刃出鞘的博客-CSDN博客
简介
本文介绍gradle的一些配置文件。包括：init.gradle, settings.gradle、
init.gradle
简介
init.gradle文件在build开始之前执行，可以在这个文件配置一些你想预先加载的操作，例如：指定仓库的地址、build日志输出，机器信息（比如jdk安装目录），build时所必需的个人信息（比如仓库或者数据库的认证信息）
启用init.gradle文件的方法
1、在命令行指定文件，例如：gradle –init-script yourdir/init.gradle -q taskName.你可以多次输入此命令来指定多个init文件
2、把init.gradle文件放到USER_HOME/.gradle/ 目录下.
3、把以.gradle结尾的文件放到USER_HOME/.gradle/init.d/ 目录下.
4、把以.gradle结尾的文件放到GRADLE_HOME/init.d/ 目录下.
如果存在上面的4种方式的2种以上，gradle会按上面的1-4序号依次执行这些文件，如果给定目录下存在多个init脚本，会按拼音a-z顺序执行这些脚本。
示例1：将慢的仓库改为阿里仓库
见：gradle--使用阿里仓库加快下载速度_IT利刃出鞘的博客-CSDN博客
示例2：指定maven本地库
在build执行之前给所有的项目指定maven本地库，同时在 build.gradle文件指定了maven的仓库中心。
build.gradle
repositories {
mavenCentral()
}
task showRepos << {
println "All repos:"
println repositories.collect { it.name }
}init.gradle
allprojects {
repositories {
mavenLocal()
}
}在命令行输入命令:gradle –init-script init.gradle -q showRepos
执行结果
> gradle --init-script init.gradle -q showRepos
All repos:
[MavenLocal, MavenRepo]settings.gradle
简介
settings.gradle作用就是用于多项目构建。多项目构成：allProjects = root项目+各子项目
写法
写法1：
rootProject.name = 'proj_root'
include 'proj_1'
include 'proj_2'
include 'group_A:proj_3_1'
include 'group_B:proj_4_2'写法2：
rootProject.name = 'proj_root'
include 'proj_1', 'proj_2', 'group_A:proj_3_1', 'group_B:proj_4_2'自定义
默认结果
假设settings.gradle这样写
rootProject.name = 'A'
include 'core', 'web', 'mobile'运行gradle projects可得到项目结构
Root project 'A'
+--- Project ':core'
+--- Project ':mobile'
\--- Project ':web'最终的文件以及目录结构如下所示：
A
--settings.gradle
--build.gradle
--core
--build.gradle
--web
--build.gradle
--mobile
--build.gradle自定义：子项目与根项目的settings.gradle同级
如果不喜欢这种默认的结构，也可以按照如下方式定义子项目的名称和物理目录结构：
settings.gradle
rootProject.name = 'A'
include(':core')
project(':core').projectDir = new File(settingsDir, 'core')
include(':web')
project(':web').projectDir = new File(settingsDir, 'web')
include(':mobile')
project(':mobile').projectDir = new File(settingsDir, 'mobile')这个例子中，子项目core实际上对应的物理目录为A/core-xxx，web实际上对应的是A/web-xxx，mobile也类似。也就是：
A
settings.gradle
build.gradle
core
build.gradle
web
build.gradle
mobile
build.gradle虽然我们更改了子项目的物理目录结构，不过由于我们在build.gradle中使用的是类似 “ :<SubProject>”的方式访问对应的子项目，所以目录结构的改变，对我们Gradle的构建脚本并不会产生影响。
此时执行gradle projects，结果仍然是
Root project 'A'
+--- Project ':core'
+--- Project ':mobile'
\--- Project ':web'自定义：子项目与根项目同级
如果不喜欢这种默认的结构，也可以按照如下方式定义子项目的名称和物理目录结构：
settings.gradle
rootProject.name = 'A'
include(':core')
project(':core').projectDir = new File(settingsDir, '../core')
include(':web')
project(':web').projectDir = new File(settingsDir, '../web')
include(':mobile')
project(':mobile').projectDir = new File(settingsDir, '../mobile')这个例子中，子项目core实际上对应的物理目录为core，web实际上对应的是web，mobile也类似。即：
A
settings.gradle
build.gradle
core
build.gradle
web
build.gradle
mobile
build.gradle虽然我们更改了子项目的物理目录结构，不过由于我们在build.gradle中使用的是类似 “ :<SubProject>”的方式访问对应的子项目，所以目录结构的改变，对我们Gradle的构建脚本并不会产生影响。
此时执行gradle projects，结果仍然是
Root project 'A'
+--- Project ':core'
+--- Project ':mobile'
\--- Project ':web'gradle.properties
用途
可以自定义某些自定义设置。如 ：依赖的版本（如SpringBoot）、JVM 内存设置，Java home，守护进程的开/关等。
跟build.gradle里边的ext{}有一样的作用，见：gradle系列--build.gradle_feiying0canglang的博客-CSDN博客
这些配置将会按以下顺序被应用（以防在多个地方都有配置时只有最后一个 生效）：
- 位于项目构建目录的gradle.properties。
- 位于gradle 用户主目录的gradle.properties。
- 系统属性，例如当在命令行中使用 -Dsome.property 时。
实例
gradle.properties
lombokVersion = '1.18.10'build.gradle
dependencies {
compile("org.projectlombok:lombok:${lombokVersion}")
}其他设置属性的方法
命令行中通过-D或者-P给Gradle实时创建属性。
-D属性会被传送给启动Gradle的jvm，作为一个系统属性被jvm使用。
build.gradle
task hello << {
println "hello, $guestName"
}命令行执行结果
$ gradle hello -DguestName='Bowen' -q
Bowen-P属性则会被直接加载到Gradle领域对象上。
build.gradle
task hello << {
println "hello, $guestName"
}命令行执行结果
$ gradle hello -PguestName='Bowen' -q
hello, Bowen如果有systemProp.前缀的属性会被识别为系统属性。
gradle.properties
systemProp.guestName = 'Bowen'build.gradle
task hello << {
println "hello, " + System.properties['guestName']
}命令行执行结果
$ gradle hello -q
hello, Bowen将特殊前缀的系统属性或环境变量自动加入到Gradle领域对象中。
如果有环境变量以ORG_GRADLE_PROJECT.为前缀，那么该变量会被自动添加到Gradle领域对象中。如果有系统属性以org.gradle.project.为前缀，那么也会被自动加入到Gradl领域对象中。这一特性的目的之一是为了隐藏一些敏感的信息。比如在执行Gradle脚本时需要传入密码信息，如果以-P的方式传送会被别人看到。而把该属性保存为环境变量，只有系统管理员才有权访问和修改。在运行Gralde的时候该环境变量会被自动加入到Gradle对象中被使用，隔离了明暗数据，又不行影响其他用户使用。（其他用户可以通过-P方式设置该属性）。
build.gradle
task hello << {
println "hello, " + guestName
}命令行执行结果
$ gradle hello -Dorg.gradle.project.guestName=Bowen -q
hello, Bowen
$ export ORG_GRADLE_PROJECT_guestName=Bob
$ gradle hello -q
hello, Bobgradle-wrapper.properties
为什么需要Gradle Wrapper
若每个成员都在电脑中安装Gradle，这时运行Gradle的环境和版本就会对构建结果带来不确定性。
Gradle Wrapper就是此问题的解决方案。Gradle Wrapper是对Gradle的一层包装，它是一个脚本，可自动下载安装Gradle，运行Gradle构建，且能指定Gradle版本，这样就标准化了项目。Idea在新建项目时会自带Gradle Wrapper。
相关命令
Idea在创建项目时，会执行gradle wrapper命令，生成以下文件
|____gradle
| |____wrapper
| | |____gradle-wrapper.jar //具体业务逻辑
| | |____gradle-wrapper.properties //配置文件
|____gradlew //Linux 下可执行脚本
|____gradlew.bat //Windows 下可执行脚本终端执行gradle wrapper生成相关文件时，可指定如下参数，控制wrapper的生成：
Wrapper配置参数：
--gradle-version 用于指定使用的Gradle版本
--gradle-distribution-url 用于指定下载Gradle发行版的url地址
例如：gradle wrapper --gradle-version 4.1
表示配置 wrapper使用4.1版本Gradle,文件gradle-wrapper.properties中的distributionUrl的规则是http\://services.gradle.org/distributions/gradle-${gradleVersion}-bin.sip。若不设置，则会默认使用当前安装的Gradle版本。
当使用Gradle Wrapper启动Gradle时，如果指定版本的Gradle没有被下载关联，会先从distributionUrl下载该版本Gradle到用户本地，进行解包并执行批处理文件。后续的构建运行都会重用这个解包的运行时安装程序。
gradle-wrapper.properties说明
gradle-wrapper.properties：
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-5.2.1-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
- distributionBase：Gradle解包后存储的主目录。
对于Idea，是：File=>Settings=> Build,Execution,Deployment=> Build Tools=> Gradle=> Gradle user home - distributionPath：distributionBase指定目录的子目录。
distributionBase+distributionPath就是Gradle解包后的存放位置。 - distributionUrl：Gradle发行版压缩包的下载地址。
- zipStoreBase：Gradle压缩包存储主目录。
- zipStorePath：zipStoreBase指定目录的子目录。
zipStoreBase+zipStorePath就是Gradle压缩包的存放位置。
6516
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
