第五十六章. 多项目构建

让我们从一个非常简单的多项目构建开始。毕竟 Gradle 核心上是一个通用的构建工具，因此所构建的项目不一定得是 Java 项目。我们的第一个例子是关于海洋生物的。
Let's start with a very simple multi-project build. After all Gradle is a general purpose build tool at its core, so the projects don't have to be java projects. Our first examples are about marine life.

water/
  build.gradle
  settings.gradle
  bluewhale/

include 'bluewhale'

Closure cl = { task -> println "I'm $task.project.name" }
task hello << cl
project(':bluewhale') {
    task hello << cl
}

> gradle -q hello
I'm water
I'm bluewhale

water/
  build.gradle
  settings.gradle
  bluewhale/
  krill/

include 'bluewhale', 'krill'

allprojects {
    task hello << { task -> println "I'm $task.project.name" }
}

> gradle -q hello
I'm water
I'm bluewhale
I'm krill

Project API 还提供了一个属性只用于访问子项目。
The Project API also provides a property for accessing the subprojects only.

allprojects {
    task hello << {task -> println "I'm $task.project.name" }
}
subprojects {
    hello << {println "- I depend on water"}
}

> gradle -q hello
I'm water
I'm bluewhale
- I depend on water
I'm krill
- I depend on water

allprojects {
    task hello << {task -> println "I'm $task.project.name" }
}
subprojects {
    hello << {println "- I depend on water"}
}
project(':bluewhale').hello << {
    println "- I'm the largest animal that has ever lived on this planet."
}

> gradle -q hello
I'm water
I'm bluewhale
- I depend on water
- I'm the largest animal that has ever lived on this planet.
I'm krill
- I depend on water

water/
  build.gradle
  settings.gradle
  bluewhale/
    build.gradle
  krill/
    build.gradle

include 'bluewhale', 'krill'

hello.doLast { println "- I'm the largest animal that has ever lived on this planet." }

hello.doLast {
    println "- The weight of my species in summer is twice as heavy as all human beings."
}

allprojects {
    task hello << {task -> println "I'm $task.project.name" }
}
subprojects {
    hello << {println "- I depend on water"}
}

> gradle -q hello
I'm water
I'm bluewhale
- I depend on water
- I'm the largest animal that has ever lived on this planet.
I'm krill
- I depend on water
- The weight of my species in summer is twice as heavy as all human beings.

water/
  build.gradle
  settings.gradle
  bluewhale/
    build.gradle
  krill/
    build.gradle
  tropicalFish/

include 'bluewhale', 'krill', 'tropicalFish'

allprojects {
    task hello << {task -> println "I'm $task.project.name" }
}
subprojects {
    hello << {println "- I depend on water"}
}
configure(subprojects.findAll {it.name != 'tropicalFish'}) {
    hello << {println '- I love to spend time in the arctic waters.'}
}

> gradle -q hello
I'm water
I'm bluewhale
- I depend on water
- I love to spend time in the arctic waters.
- I'm the largest animal that has ever lived on this planet.
I'm krill
- I depend on water
- I love to spend time in the arctic waters.
- The weight of my species in summer is twice as heavy as all human beings.
I'm tropicalFish
- I depend on water

water/
  build.gradle
  settings.gradle
  bluewhale/
    build.gradle
  krill/
    build.gradle
  tropicalFish/
    build.gradle

include 'bluewhale', 'krill', 'tropicalFish'

ext.arctic = true
hello.doLast { println "- I'm the largest animal that has ever lived on this planet." }

ext.arctic = true
hello.doLast {
    println "- The weight of my species in summer is twice as heavy as all human beings."
}

ext.arctic = false

allprojects {
    task hello << {task -> println "I'm $task.project.name" }
}
subprojects {
    hello {
        doLast {println "- I depend on water"}
        afterEvaluate { Project project ->
            if (project.arctic) { doLast {
                println '- I love to spend time in the arctic waters.' }
            }
        }
    }
}

> gradle -q hello
I'm water
I'm bluewhale
- I depend on water
- I'm the largest animal that has ever lived on this planet.
- I love to spend time in the arctic waters.
I'm krill
- I depend on water
- The weight of my species in summer is twice as heavy as all human beings.
- I love to spend time in the arctic waters.
I'm tropicalFish
- I depend on water

当我们从根项目目录执行了 hello 任务时，会以一种直观的方式表现出来。不同项目中的所有 hello 任务都被执行了。让我们切换到 bluewhale 目录，看看如果我们在那里执行 Gradle，会发生什么。
When we have executed the hello task from the root project dir things behaved in an intuitive way. All the hello tasks of the different projects were executed. Let's switch to the bluewhale dir and see what happens if we execute Gradle from there.

> gradle -q hello
I'm bluewhale
- I depend on water
- I'm the largest animal that has ever lived on this planet.
- I love to spend time in the arctic waters.

Gradle 的行为背后的基本规则很简单。Gradle 从当前目录开始，按层次结构往下查找名为 hello 的任务并执行它们。有一件事很重要。Gradle 始终评估多项目构建的每一个项目，并创建所有存在的任务对象。然后，根据任务名称参数和当前目录， Gradle 过滤出应该执行的任务。由于 Gradle 的跨项目配置，每个项目都必须在执行任何任务之前先评估。我们将在下一节仔细研究这一点。现在让我们看看最后一个 marine 的例子。 我们先将任务添加到 bluewhale 和 krill。
The basic rule behind Gradle's behavior is simple. Gradle looks down the hierarchy, starting with the current dir, for tasks with the name hello an executes them. One thing is very important to note. Gradle always evaluates every project of the multi-project build and creates all existing task objects. Then, according to the task name arguments and the current dir, Gradle filters the tasks which should be executed. Because of Gradle's cross project configuration every project has to be evaluated before any task gets executed. We will have a closer look at this in the next section. Let's now have our last marine example. Let's add a task to bluewhale and krill.

ext.arctic = true
hello << { println "- I'm the largest animal that has ever lived on this planet." }

task distanceToIceberg << {
    println '20 nautical miles'
}

ext.arctic = true
hello << { println "- The weight of my species in summer is twice as heavy as all human beings." }

task distanceToIceberg << {
    println '5 nautical miles'
}

> gradle -q distanceToIceberg
20 nautical miles
5 nautical miles

不使用 -q 选项的输出结果︰
Here the output without the -q option:

> gradle distanceToIceberg
:bluewhale:distanceToIceberg
20 nautical miles
:krill:distanceToIceberg
5 nautical miles

BUILD SUCCESSFUL

Total time: 1 secs

构建从 water 项目执行。water 和 tropicalFish 都没有一个叫 distanceToIceberg的任务，但 Gradle 不关心这个问题。上面提到的简单规则是：执行这个层次结构下叫这个名字的所有任务。如果没有这样的任务，只能报错！
The build is executed from the water project. Neither water nor tropicalFish have a task with the name distanceToIceberg. Gradle does not care. The simple rule mentioned already above is: Execute all tasks down the hierarchy which have this name. Only complain if there is no such task!

如我们所见，你可以通过进入任意的子项目目录并从该处执行构建来运行多项目构建。从当前目录开始的项目层次结构中，所有名字匹配的任务都会被执行。不过 Gradle 也提供了按绝对路径来执行任务的方式（另请参阅《第56.5节，项目和任务路径》）：
As we have seen, you can run a multi-project build by entering any subproject dir and execute the build from there. All matching task names of the project hierarchy starting with the current dir are executed. But Gradle also offers to execute tasks by their absolute path (see also Section 56.5, “Project and task paths”):

> gradle -q :hello :krill:hello hello
I'm water
I'm krill
- I depend on water
- The weight of my species in summer is twice as heavy as all human beings.
- I love to spend time in the arctic waters.
I'm tropicalFish
- I depend on water

构建从 tropicalFish 项目执行。我们执行了 water， hello 及 tropicalFish 这三个项目的 hello 任务。 前两个任务由其绝对路径指定，最后一个任务通过上面所述的名称匹配机制执行。
The build is executed from the tropicalFish project. We execute the hello tasks of the water, the krill and the tropicalFish project. The first two tasks are specified by there absolute path, the last task is executed on the name matching mechanism described above.

项目路径具有以下模式：它始终以冒号开头，表示根项目。根项目是路径中唯一不由其名称指定的项目。路径 :bluewhale 对应于上面示例中的文件系统路径 water/bluewhale 。
A project path has the following pattern: It starts always with a colon, which denotes the root project. The root project is the only project in a path that is not specified by its name. The path :bluewhale corresponds to the file system path water/bluewhale in the case of the example above.

任务的路径只是它的项目路径加上任务名称。 例如 :bluewhale:hello。在项目中，您可以通过任务的名称来处理同一项目的任务，这被解释为相对路径。
The path of a task is simply its project path plus the task name. For example :bluewhale:hello. Within a project you can address a task of the same project just by its name. This is interpreted as a relative path.

最初 Gradle 使用 “/” 字符作为自然路径分隔符。在引入目录任务（见《第14.1节，目录创建)》就不能再这样做了，因为目录任务的名称包含 “/” 字符。
Originally Gradle has used the '/' character as a natural path separator. With the introduction of directory tasks (see Section 14.1, “Directory creation”) this was no longer possible, as the name of the directory task contains the '/' character.

上一节的例子比较特殊，因为项目里没有执行依赖，只有配置依赖。下面是一个不同的例子：
The examples from the last section were special, as the projects had no Execution Dependencies. They had only Configuration Dependencies. Here is an example where this is different:

messages/
  settings.gradle
  consumer/
    build.gradle
  producer/
    build.gradle

include 'consumer', 'producer'

task action << {
    println("Consuming message: ${rootProject.producerMessage}")
}

task action << {
    println "Producing message:"
    rootProject.producerMessage = 'Watch the order of execution.'
}

> gradle -q action
Consuming message: null
Producing message:

messages/
  settings.gradle
  aProducer/
    build.gradle
  consumer/
    build.gradle

include 'consumer', 'aProducer'

task action << {
    println "Producing message:"
    rootProject.producerMessage = 'Watch the order of execution.'
}

task action << {
    println("Consuming message: ${rootProject.producerMessage}")
}

> gradle -q action
Producing message:
Consuming message: Watch the order of execution.

> gradle -q action
Consuming message: null

messages/
  settings.gradle
  consumer/
    build.gradle
  producer/
    build.gradle

include 'consumer', 'producer'

task action(dependsOn: ":producer:action") << {
    println("Consuming message: ${rootProject.producerMessage}")
}

task action << {
    println "Producing message:"
    rootProject.producerMessage = 'Watch the order of execution.'
}

> gradle -q action
Producing message:
Consuming message: Watch the order of execution.

> gradle -q action
Producing message:
Consuming message: Watch the order of execution.

task consume(dependsOn: ':producer:produce') << {
    println("Consuming message: ${rootProject.producerMessage}")
}

task produce << {
    println "Producing message:"
    rootProject.producerMessage = 'Watch the order of execution.'
}

> gradle -q consume
Producing message:
Consuming message: Watch the order of execution.

def message = rootProject.producerMessage

task consume << {
    println("Consuming message: " + message)
}

rootProject.producerMessage = 'Watch the order of evaluation.'

> gradle -q consume
Consuming message: null

evaluationDependsOn(':producer')

def message = rootProject.producerMessage

task consume << {
    println("Consuming message: " + message)
}

> gradle -q consume
Consuming message: Watch the order of evaluation.

task consume << {
    println("Consuming message: ${rootProject.producerMessage}")
}

> gradle -q consume
Consuming message: Watch the order of evaluation.

webDist/
  settings.gradle
  build.gradle
  date/
    src/main/java/
      org/gradle/sample/
        DateServlet.java
  hello/
    src/main/java/
      org/gradle/sample/
        HelloServlet.java

include 'date', 'hello'

allprojects {
    apply plugin: 'java'
    group = 'org.gradle.sample'
    version = '1.0'
}

subprojects {
    apply plugin: 'war'
    repositories {
        mavenCentral()
}
    }
    dependencies {
        compile "javax.servlet:servlet-api:2.5"
    }
}

task explodedDist(dependsOn: assemble) << {
    File explodedDist = mkdir("$buildDir/explodedDist")
    subprojects.each {project ->
        project.tasks.withType(Jar).each {archiveTask ->
            copy {
                from archiveTask.archivePath
                into explodedDist
            }
        }
    }
}

如果一个项目在其编译路径上需要另一个项目生成的 jar 呢？并且不仅是 jar，还有它的传递依赖呢？显然，这是 Java 多项目构建中非常常见的情况。如《第50.4.3节，项目依赖》中所述，Gradle 为此提供了项目库依赖。
What if one projects needs the jar produced by another project in its compile path? And not just the jar but also the transitive dependencies of this jar? Obviously this is a very common use case for Java multi-project builds. As already mentioned in Section 50.4.3, “Project dependencies”, Gradle offers project lib dependencies for this.

java/
  settings.gradle
  build.gradle
  api/
    src/main/java/
      org/gradle/sample/
        api/
          Person.java
        apiImpl/
          PersonImpl.java
  services/personService/
    src/
      main/java/
        org/gradle/sample/services/
          PersonService.java
      test/java/
        org/gradle/sample/services/
          PersonServiceTest.java
  shared/
    src/main/java/
      org/gradle/sample/shared/
        Helper.java

我们有这些项目：shared，api 和 personService。personService 对其他两个项目有一个库依赖，api 对 shared上有一个库依赖。^[22]
We have the projects shared, api andpersonService. personService has a lib dependency on the other two projects. api has a lib dependency on shared. ^[22]

include 'api', 'shared', 'services:personService'

subprojects {
    apply plugin: 'java'
    group = 'org.gradle.sample'
    version = '1.0'
    repositories {
        mavenCentral()
}
    }
    dependencies {
        testCompile "junit:junit:4.11"
    }
}

project(':api') {
    dependencies {
        compile project(':shared')
    }
}

project(':services:personService') {
    dependencies {
        compile project(':shared'), project(':api')
    }
}

所有构建逻辑都在根项目的 build.gradle 中。 ^[23]库依赖是执行依赖的一种特殊形式。它会首先构建另一个项目，并把其他项目的 jar 文件和类一起添加到类路径中。它还将其他项目的依赖也添加到类路径。因此你可以进入 api 目录并触发 gradle compile。首先构建 shared，然后构建 api。项目依赖支持部分多项目构建。
All the build logic is in the build.gradle of the root project. ^[23] A lib dependency is a special form of an execution dependency. It causes the other project to be built first and adds the jar with the classes of the other project to the classpath. It also adds the dependencies of the other project to the classpath. So you can enter the api directory and trigger a gradle compile. First shared is built and then api is built. Project dependencies enable partial multi-project builds.

如果你是从 Maven 转过来的，你会对这一点很满意的。如果你是从 Ivy 转过来，你可能还想要一些更细粒度的控制。Gradle 向你提供了这种控制：
If you come from Maven land you might be perfectly happy with this. If you come from Ivy land, you might expect some more fine grained control. Gradle offers this to you:

subprojects {
    apply plugin: 'java'
    group = 'org.gradle.sample'
    version = '1.0'
}

project(':api') {
    configurations {
        spi
    }
    dependencies {
        compile project(':shared')
    }
    task spiJar(type: Jar) {
        baseName = 'api-spi'
        dependsOn classes
        from sourceSets.main.output
        include('org/gradle/sample/api/**')
    }
    artifacts {
        spi spiJar
    }
}

project(':services:personService') {
    dependencies {
        compile project(':shared')
        compile project(path: ':api', configuration: 'spi')
        testCompile "junit:junit:4.11", project(':api')
    }
}

Java 插件将每个默认的 jar 添加到包含所有类的项目库中。在这个例子中，我们创建了一个额外的库，它只包含 api 项目的接口。 我们把这个库指定给一个新的依赖配置。对于 person service，我们声明这个项目应该只针对 api 接口进行编译，但使用 api 中的所有类进行测试。
The Java plugin adds per default a jar to your project libraries which contains all the classes. In this example we create an additional library containing only the interfaces of the api project. We assign this library to a new dependency configuration. For the person service we declare that the project should be compiled only against the api interfaces but tested with all classes from api.

随着在开发人员的台式机和 CI 服务器上，有越来越多的 CPU 内核可用，Gradle 能够充分利用这些处理资源就很重要。更具体地说，并行执行将尝试：
With more and more CPU cores available on developer desktops and CI servers, it is important that Gradle is able to fully utilise these processing resources. More specifically, the parallel execution attempts to:

虽然 Gradle 已通过 Test.setMaxParallelForks() 提供了并行测试执行，本节中描述的功能是项目级别的并行执行。并行执行是一个实验性的功能，请使用它，并让我们知道它是如何为你处理的。
Although Gradle already offers parallel test execution via Test.setMaxParallelForks() the feature described in this section is parallel execution at a project level. Parallel execution is an incubating feature. Please use it and let us know how it works for you.

并行项目执行允许在一个解耦的多项目构建中的一些单独项目并行执行（另请参阅《第56.9节，解耦项目》）。虽然并行执行并不严格要求在配置时进行解耦，但它的长期目标是提供一组强大的功能部件，用于完全解耦项目。这些功能包括：
Parallel project execution allows the separate projects in a decoupled multi-project build to be executed in parallel (see also: Section 56.9, “Decoupled Projects”). While parallel execution does not strictly require decoupling at configuration time, the long-term goal is to provide a powerful set of features that will be available for fully decoupled projects. Such features include:

并行执行是怎么做的？首先，你需要告诉 Gradle 使用并行模式。你可以使用命令行参数（《附录D，Gradle 命令行》），或者是配置你的构建环境（《第20.1节，通过 gradle.properties 配置构建环境》）。除非你指定并行线程的个数，否则 Gradle 将根据可用的 CPU 内核来选择正确的线程数。当执行一个任务时，每个并行的工作线程都专用于一个给定的项目。这意味着同一项目中的两个任务永远不会并行执行。因此，只有多项目构建可以利用并行执行。并行执行完全支持任务依赖，并且并行线程将首先开始执行上游任务。记住，解耦的任务按字母顺序调度，且顺序执行，并不是真正的以并行模式执行。你需要确保正确声明了任务依赖，以避免排序问题。
How does the parallel execution work? First, you need to tell Gradle to use the parallel mode. You can use the command line argument (Appendix D, Gradle Command Line) or configure your build environment (Section 20.1, “Configuring the build environment via gradle.properties”). Unless you provide specific number of parallel threads Gradle attempts to choose the right number based on available CPU cores. Every parallel worker exclusively owns a given project while executing a task. This means that 2 tasks from the same project are never executed in parallel. Therefore only multi-project builds can take advantage of parallel execution. Task dependencies are fully supported and parallel workers will start executing upstream tasks first. Bear in mind that the alphabetical scheduling of decoupled tasks, known from the sequential execution, does not really work in parallel mode. You need to make sure the task dependencies are declared correctly to avoid ordering issues.

Gradle 允许任何项目在配置和执行阶段期间访问其他项目。虽然这为构建作者提供了很大的控制性和灵活性，但也限制了 Gradle 在构建这些项目时本身所具有的灵活性。例如，项目的紧耦合会阻碍 Gradle 以并行方式构建多项目，或阻碍以预构建的工件替代项目依赖。
Gradle allows any project to access any other project during both the configuration and execution phases. While this provides a great deal of power and flexibility to the build author, it also limits the flexibility that Gradle has when building those projects. For instance, this tight coupling of projects effectively prevents Gradle from building multiple projects in parallel, or from substituting a pre-built artifact in place of a project dependency.

如果两个项目不直接访问彼此的项目模型，那么它们就被认为是解耦的。解耦的项目可能只在声明依赖方面会互相影响：项目依赖（《第50.4.3节，项目依赖》），或者是任务依赖（《第6.5节，任务依赖》）。任何其他形式的项目交互（即通过修改另一个项目对象或从另一个项目对象中读值)都会导致项目耦合。
Two projects are said to be decoupled if they do not directly access each other's project model. Decoupled projects may only interact in terms of declared dependencies: project dependencies (Section 50.4.3, “Project dependencies”) and/or task dependencies (Section 6.5, “Task dependencies”). Any other form of project interaction (i.e. by modifying another project object or by reading a value from another project object) causes the projects to be coupled.

通过使用配置注入（《第56.1节，跨项目配置》），是一种很常见的使项目耦合的方式。它可能不明显，但是使用关键的 Gradle 功能如 allprojects 和 subproject 关键字，会自动导致你的项目耦合。这是因为这些关键字在定义项目的 build.gradle 文件中使用。而通常这是一个“根项目”，它只定义公共配置而不执行其他操作，但对 Gradle 而言这个根项目仍然是一个完全成熟的项目，并且通过使用 allprojects，该项目实际上就和所有其他项目耦合了。
A very common way for projects to be coupled is by using configuration injection (Section 56.1, “Cross project configuration”). It may not be immediately apparent, but using key Gradle features like the allprojects and subprojects keywords automatically cause your projects to be coupled. This is because these keywords are used in a build.gradle file, which defines a project. Often this is a "root project" that does nothing more than define common configuration, but as far as Gradle is concerned this root project is still a fully-fledged project, and by using allprojects that project is effectively coupled to all other projects.

这意味着使用任何形式的共享构建脚本逻辑或配置注入(allproject，subprojects等）都会导致你的项目耦合。当我们扩展项目解耦的概念，并提供利用去耦项目的功能时，我们也将引入新功能来帮助你解决常见的情况（如配置注入）而不会导致项目耦合。
This means that using any form of shared build script logic or configuration injection (allprojects, subprojects, etc.) will cause your projects to be coupled. As we extend the concept of project decoupling and provide features that take advantage of decoupled projects, we will also introduce new features to help you to solve common use cases (like configuration injection) without causing your projects to be coupled.

Java 插件的 build 任务通常用于一个项目的编译、测试和执行代码风格检查（如果使用了 CodeQuality 插件的话)。在多项目构建中，你可能经常想在一系列项目中执行所有这些任务。buildNeeded 和 buildDependents 任务能够帮助完成这一点。
The build task of the Java plugin is typically used to compile, test, and perform code style checks (if the CodeQuality plugin is used) of a single project. In multi-project builds you may often want to do all of these tasks across a range of projects. The buildNeeded and buildDependents tasks can help with this.

我们使用示例 56.25，项目库依赖中显示的项目结构。在此示例中，:services:personservice 依赖于 :api 和 :shared。:api 项目还依赖于:shared。
Let's use the project structure shown in Example 56.25, “Project lib dependencies”. In this example :services:personservice depends on both :api and :shared. The :api project also depends on :shared.

假设你正在处理 :api 这一个项目，你做了一些修改，但由于执行了 clean 以来还没有构建整个项目。你希望构建所有必需的支持 jar，但只对这个做了修改的项目执行代码质量和单元测试，这正是 build 任务执行的。
Assume you are working on a single project, the :api project. You have been making changes, but have not built the entire project since performing a clean. You want to build any necessary supporting jars, but only perform code quality and unit tests on the project you have changed. The build task does this.

> gradle :api:build
:shared:compileJava
:shared:processResources
:shared:classes
:shared:jar
:api:compileJava
:api:processResources
:api:classes
:api:jar
:api:assemble
:api:compileTestJava
:api:processTestResources
:api:testClasses
:api:test
:api:check
:api:build

BUILD SUCCESSFUL

Total time: 1 secs

当你在典型的开发周期中反复构建并测试对 :api 项目所作的修改（要知道你只修改了这个项目中的一个文件）时，你可能不想查看 :shared 项目中所修改的内容时承担 :shared:compile 检查的成本。添加 -a 选项能够让 Gradle 使用缓存的 jar 来解析所有项目库依赖，而不会尝试重新构建所依赖的项目。
While you are working in a typical development cycle repeatedly building and testing changes to the :api project (knowing that you are only changing files in this one project), you may not want to even suffer the expense of :shared:compile checking to see what has changed in the :shared project. Adding the -a option will cause Gradle to use cached jars to resolve any project lib dependencies and not try to re-build the depended on projects.

> gradle -a :api:build
:api:compileJava
:api:processResources
:api:classes
:api:jar
:api:assemble
:api:compileTestJava
:api:processTestResources
:api:testClasses
:api:test
:api:check
:api:build

BUILD SUCCESSFUL

Total time: 1 secs

如果你刚从版本控制系统中获取到最新的代码，其中包含了 :api 所依赖的其他项目的修改，那么你可能不只想构建所依赖的所有项目，还要对其进行测试。buildNeeded 任务也用于测试 testRuntime 配置中项目库依赖所配置的所有项目。
If you have just gotten the latest version of source from your version control system which included changes in other projects that :api depends on, you might want to not only build all the projects you depend on, but test them as well. The buildNeeded task also tests all the projects from the project lib dependencies of the testRuntime configuration.

> gradle :api:buildNeeded
:shared:compileJava
:shared:processResources
:shared:classes
:shared:jar
:api:compileJava
:api:processResources
:api:classes
:api:jar
:api:assemble
:api:compileTestJava
:api:processTestResources
:api:testClasses
:api:test
:api:check
:api:build
:shared:assemble
:shared:compileTestJava
:shared:processTestResources
:shared:testClasses
:shared:test
:shared:check
:shared:build
:shared:buildNeeded
:api:buildNeeded

BUILD SUCCESSFUL

Total time: 1 secs

你还可能想要重构 :api 项目中被其他项目使用的部分内容。如果你做这一类的修改，那么只测试 :api 项目是不够的，你还需要测试依赖于 :api 项目的所有项目。buildDependents 任务也用于测试依赖于（在 testRuntime 配置中）指定项目上的所有项目。
You also might want to refactor some part of the :api project that is used in other projects. If you make these types of changes, it is not sufficient to test just the :api project, you also need to test all projects that depend on the :api project. The buildDependents task also tests all the projects that have a project lib dependency (in the testRuntime configuration) on the specified project.

> gradle :api:buildDependents
:shared:compileJava
:shared:processResources
:shared:classes
:shared:jar
:api:compileJava
:api:processResources
:api:classes
:api:jar
:api:assemble
:api:compileTestJava
:api:processTestResources
:api:testClasses
:api:test
:api:check
:api:build
:services:personService:compileJava
:services:personService:processResources
:services:personService:classes
:services:personService:jar
:services:personService:assemble
:services:personService:compileTestJava
:services:personService:processTestResources
:services:personService:testClasses
:services:personService:test
:services:personService:check
:services:personService:build
:services:personService:buildDependents
:api:buildDependents

BUILD SUCCESSFUL

Total time: 1 secs

最后，你可能想要构建和测试所有项目中的所有内容。在根项目文件夹中运行的任何任务，都会导致所有子项目中的同名任务也被运行。因此，你可以只运行 gradle build 来构建和测试所有项目。
Finally, you may want to build and test everything in all projects. Any task you run in the root project folder will cause that same named task to be run on all the children. So you can just run gradle build to build and test all projects.

项目中声明的属性和方法将继承到所有子项目。这是配置注入的替代方法，但我们认为，继承的模式并不能反映多项目构建的问题空间。在本用户指南的未来版本中，我们可能会写一下与之有关的更多内容。
Properties and methods declared in a project are inherited to all its subprojects. This is an alternative to configuration injection. But we think that the model of inheritance does not reflect the problem space of multi-project builds very well. In a future edition of this user guide we might write more about this.

方法继承可能值得使用，尽管 Gradle 的配置注入还不支持方法（但会在以后的版本中支持的）。
Method inheritance might be interesting to use as Gradle's Configuration Injection does not support methods yet (but will in a future release).

你可能想知道，为什么我们实现了一个我们显然不喜欢的功能。原因之一是其他工具也有这个功能，而我们希望在功能比较中有这一点:)。我们想为我们的用户提供一种选择。
You might be wondering why we have implemented a feature we obviously don't like that much. One reason is that it is offered by other tools and we want to have the check mark in a feature comparison :). And we like to offer our users a choice.

写这一章相当耗费精力，可能你读起来也有同样的感受。我们对这一章最后要说的是，使用 Gradle 的多项目构建通常不难。你需要记住五个元素：allproject， subproject，evaluationDependsOn，evaluationDependsOnChildren 和项目库依赖。^[24] 使用这些元素，并记住 Gradle 有不同的配置和执行阶段，你就已经可以很灵活地运用它。但当你进入一个陡峭的领域时，Gradle 不会成为你的障碍，并且通常会伴随你带你到峰顶。
Writing this chapter was pretty exhausting and reading it might have a similar effect. Our final message for this chapter is that multi-project builds with Gradle are usually not difficult. There are five elements you need to remember: allprojects, subprojects, evaluationDependsOn, evaluationDependsOnChildren and project lib dependencies. ^[24] With those elements, and keeping in mind that Gradle has a distinct configuration and execution phase, you have already a lot of flexibility. But when you enter steep territory Gradle does not become an obstacle and usually accompanies and carries you to the top of the mountain.