Gradle: build.gradle vs. settings.gradle vs. gradle.properties – Gradle：build.gradle vs. settings.gradle vs. gradle.properties

最后修改: 2018年 10月 8日

中文/混合/英文(键盘快捷键：t)

1. Overview

1.概述

In this article, we’ll look at the different configuration files of a Gradle Java project. Also, we’ll see the details of an actual build.

在这篇文章中，我们将看看Gradle Java项目的不同配置文件。此外，我们还将看到实际构建的细节。

You can check this article for a general introduction to Gradle.

你可以查看这篇文章，了解对Gradle的一般介绍。

2. build.gradle

2.build.gradle

Let’s assume that we’re just creating a new Java project by running gradle init –type java-application. This’ll leave us with a new project with the following directory and file structure:

让我们假设，我们只是通过运行gradle init -type java-application来创建一个新的Java项目。这将给我们留下一个新项目，其目录和文件结构如下。

build.gradle
gradle    
    wrapper
        gradle-wrapper.jar
        gradle-wrapper.properties
gradlew
gradlew.bat
settings.gradle
src
    main
        java  
            App.java
    test      
        java
            AppTest.java

We can consider the build.gradle file as the heart or the brain of the project. The resulting file for our example looks like this:

我们可以把build.gradle文件视为项目的心脏或大脑。我们的例子的结果文件看起来像这样。

plugins {
    id 'java'
    id 'application'
}

mainClassName = 'App'

dependencies {
    compile 'com.google.guava:guava:23.0'

    testCompile 'junit:junit:4.12'
}

repositories {
    jcenter()
}

It consists of Groovy code, or more precisely, a Groovy-based DSL (domain specific language) for describing the builds. We can define our dependencies here and also add things like Maven repositories used for dependency resolution.

它由Groovy代码组成，或者更准确地说，是一种基于Groovy的DSL（特定领域语言），用于描述构建。我们可以在这里定义我们的依赖关系，也可以添加用于依赖关系解析的Maven仓库等内容。。

The fundamental building blocks of Gradle are projects and tasks. In this case, since the java plugin is applied, all necessary tasks for building a Java project are defined implicitly. Some of those tasks are assemble, check, build, jar, javadoc, clean and many more.

Gradle的基本构建模块是项目和任务。在这种情况下，由于应用了java插件，所有构建Java项目的必要任务都被隐含地定义了。其中一些任务是assemble、check、build、jar、javadoc、clean等等。

These tasks are also set up in such a way, that they describe a useful dependency graph for a Java project, meaning it’s generally enough to execute the build task and Gradle (and the Java plugin) will make sure, that all necessary tasks are performed.

这些任务也是以这样的方式设置的，它们为Java项目描述了一个有用的依赖关系图，这意味着通常只需执行构建任务，Gradle（和Java插件）就会确保所有必要的任务都得到执行。

If we need additional specialized tasks, like, e.g., building a Docker image, it would also go into the build.gradle file. The easiest possible definition of tasks looks like this:

如果我们需要额外的专门任务，例如，构建一个Docker镜像，它也将进入build.gradle文件。最简单的任务定义是这样的。

task hello {
    doLast {
        println 'Hello Baeldung!'
    }
}

We can run a task by specifying it as an argument to the Gradle CLI like this:

我们可以像这样把一个任务作为参数指定给Gradle CLI，来运行它。

$ gradle -q hello
Hello Baeldung!

It’ll do nothing useful, but print out “Hello Baeldung!” of course.

它不会做任何有用的事情，当然会打印出 “你好，Baeldung！”。

In case of a multi-project build, we’d probably have multiple different build.gradle files, one for each project.

如果是多项目构建，我们可能会有多个不同的build.gradle文件，每个项目一个。

The build.gradle file is executed against a Project instance, with one Project instance created per subproject. The tasks above, which can be defined in the build.gradle file, reside inside the Project instance as part of a collection of Task objects. The Tasks itself consists of multiple actions as an ordered list.

build.gradle文件是针对Project实例执行的，每个子项目创建一个Project实例。上述任务可以在build.gradle文件中定义，作为Task对象集合的一部分，驻留在Project实例内。任务本身由多个动作组成，是一个有序的列表。

In our previous example, we’ve added a Groovy closure for printing out “Hello Baeldung!” to the end of this list, by calling the doLast(Closure action) on our hello Task object. During the execution of Task, Gradle is executing each of its Actions in order, by calling the Action.execute(T) method.

在我们之前的例子中，我们通过调用doLast(Closure action)在我们的helloTask对象上添加了一个用于打印出 “Hello Baeldung!”的Groovy闭包，并在这个列表的最后。在执行Task的过程中，Gradle通过调用Action.execute(T)方法，依次执行它的每个Actions。

3. settings.gradle

3.settings.gradle

Gradle also generates a settings.gradle file:

Gradle还生成了一个settings.gradle文件。

rootProject.name = 'gradle-example'

The settings.gradle file is a Groovy script as well.

settings.gradle文件也是一个Groovy脚本。

In contrast to the build.gradle file, only one settings.gradle file is executed per Gradle build. We can use it to define the projects of a multi-project build.

与build.gradle文件相比，每次Gradle构建只执行一个settings.gradle文件。我们可以用它来定义一个多项目构建的项目。

Besides, we can also possible to register code as part of different life cycle hooks of a build.

此外，我们也可以将代码注册为构建的不同生命周期钩子的一部分。

The framework requires the existence of the settings.gradle in a multi-project build, while it’s optional for a single-project build.

在多项目构建中，该框架要求存在settings.gradle，而在单项目构建中，它是可选的。

This file is used after creating the Settings instance of the build, by executing the file against it and thereby configuring it. This means that we’re defining subprojects in our settings.gradle file like this:

这个文件是在创建Settings实例后使用的，通过对它执行文件，从而配置它。这意味着我们在settings.gradle文件中这样定义子项目。

include 'foo', 'bar'

and Gradle is calling the void include(String… projectPaths) method on the Settings instance when creating the build.

而Gradle在创建构建时正在调用void include(String…projectPaths)方法，在Settings实例上。

4. gradle.properties

4.gradle.properties

Gradle doesn’t create a gradle.properties file by default. It can reside in different locations, for example in the project root directory, inside of GRADLE_USER_HOME or in the location specified by the -Dgradle.user.home command line flag.

Gradle默认不会创建一个gradle.properties文件。它可以存在于不同的位置，例如在项目根目录下，在GRADLE_USER_HOME内，或者在-Dgradle.user.home命令行标志所指定的位置。

This file consists of key-value pairs. We can use it to configure the behavior of the framework itself and it’s an alternative to using command line flags for the configuration.

这个文件由键值对组成。我们可以用它来配置框架本身的行为，它是使用命令行标志进行配置的一种替代方法。

Examples of possible keys are:

可能的键的例子是。

  • org.gradle.caching=(true,false)
  • org.gradle.daemon=(true,false)
  • org.gradle.parallel=(true,false)
  • org.gradle.logging.level=(quiet,warn,lifecycle,info,debug)

Also, you can use this file to add properties directly to the Project object, e.g., the property with its namespace: org.gradle.project.property_to_set

另外，你可以用这个文件直接向Project对象添加属性，例如，属性与它的命名空间。org.gradle.project.property_to_set。

Another use case is specifying JVM parameters like this:

另一个用例是像这样指定JVM参数。

org.gradle.jvmargs=-Xmx2g -XX:MaxPermSize=256m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Please note that it needs to launch a JVM process to parse the gradle.properties file. This means these JVM parameters only effect separately launched JVM processes.

请注意，它需要启动一个JVM进程来解析gradle.properties文件。这意味着这些JVM参数只影响单独启动的JVM进程。

5. The Build in a Nutshell

5.简而言之的建设

We can summarize the general lifecycle of a Gradle build as follows, assuming we don’t run it as a daemon:

我们可以把Gradle构建的一般生命周期总结如下，假设我们不把它作为一个守护程序来运行。

  • It launches as a new JVM process
  • It parses the gradle.properties file and configures Gradle accordingly
  • Next, it creates a Settings instance for the build
  • Then, it evaluates the settings.gradle file against the Settings object
  • It creates a hierarchy of Projects, based on the configured Settings object
  • Finally, it executes each build.gradle file against its project

6. Conclusion

6.结语

We’ve seen, how different Gradle configuration files fulfill various development purposes. We can use them to configure a Gradle build as well as Gradle itself, based on the needs of our project.

我们已经看到，不同的Gradle配置文件是如何实现各种开发目的的。我们可以根据我们项目的需要，用它们来配置Gradle构建以及Gradle本身。