第57章 マルチプロジェクトのビルド

While each subproject could configure itself in complete isolation of the other subprojects, it is common that subprojects share common traits. It is then usually preferable to share configurations among projects, so the same configuration affects several subprojects.

Let's start with a very simple multi-project build. 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.

まず、ごく簡単な例から始めましょう。なんと言ってもGradleは汎用のビルドツールですので、扱うプロジェクトがJavaプロジェクトである必要はありません。 これから例として使用するプロジェクトは、海洋生物に関するものです。

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

The Project API also provides a property for accessing the subprojects only.

プロジェクトAPIはサブプロジェクトのみにアクセスする方法も提供します。

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

When we 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.

helloタスクをルートプロジェクトのディレクトリで実行したとき、ビルドは直感に従う、自然な形で実行されました。つまり、サブプロジェクトに定義されたhelloタスクも含め、すべてのhelloタスクが実行されたのです。では、bluewhaleディレクトリでGradleを実行した場合、どのようにビルドが実行されるのでしょうか。

> 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.

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 and 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.

Gradleがビルドを実行するときの基本的なルールは単純なものです。この例では、Gradleはhelloタスクを探して、カレントディレクトリからプロジェクト階層を降りていき、タスクを見つけるとそれを実行するだけです。ただし、非常に重要な注意点が一つあります。Gradleはマルチプロジェクトに参加しているすべてのプロジェクトを常に評価します。ビルドスクリプトに定義されているタスクオブジェクトは、すべて作成されるのです。そのあと、Gradleは実行時にコマンドに引き渡したタスク名と実行ディレクトリによって、実際に実行するタスクをフィルタリングします。Gradleのクロスプロジェクト設定を実現するため、すべてのプロジェクトはタスク実行前に評価されてなければなりません。次の節では、このことについてさらに詳しく見ていきます。さて、これまで作成してきたmarineプロジェクトのbluewhaleと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

Here's the output without the -q option:

-qオプションを外すと、出力結果は以下のようになります。:

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

BUILD SUCCESSFUL

Total time: 1 secs

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!

このビルドはwaterプロジェクトのディレクトリで実行しています。waterプロジェクトもtropicalFishプロジェクトもdistanceToIcebergという名前のタスクは持っていませんが、Gradleはそんなこと気にしません。前述の実行ルールに従って、プロジェクト階層にあるdistanceToIcebergという名前のタスクをすべて実行するだけです。distanceToIcebergタスクが一つもないときだけ警告を出してきます。

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 「プロジェクトとタスクのパスProject and task paths」):

いままで見てきたように、マルチプロジェクトのサブプロジェクトは、プロジェクトのディレクトリに移動して個別にビルドできます。その場合、実行ディレクトリ以下の、指定したタスク名のタスクがすべて実行されます。また、ビルド時にタスクの絶対パスを指定することもできます。ディレクトリを移動しなくても、パスで指定したプロジェクトのタスクのみ実行できるのです。(「プロジェクトとタスクのパス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

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 their absolute path, the last task is executed using the name matching mechanism described above.

ビルドはtropicalFishプロジェクトのディレクトリで実行されています。上記の例では、ルートプロジェクトwatar、krillプロジェクト、そしてカレントのサブプロジェクトtropicalFishのhelloがそれぞれ実行されます。

A project path has the following pattern: It starts with an optional colon, which denotes the root project. The root project is the only project in a path that is not specified by its name. The rest of a project path is a colon-separated sequence of project names, where the next project is a subproject of the previous project.

The path of a task is simply its project path plus the task name, like “: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.

タスクのパスは、例えば :bluewhale:hello のように、単純にプロジェクトパスにタスク名を加えるだけです。なお、カレントのプロジェクトにあるタスクは、タスク名だけで指定できます。

Originally Gradle has used the '/' character as a natural path separator. With the introduction of directory tasks (see 「ディレクトリの作成 Directory creation」) this was no longer possible, as the name of the directory task contains the '/' character.

以前Gradleでは、プロジェクトのパスセパレータとして「/」を使用していました。しかし、このセパレータ文字はdirectoryタスク(「ディレクトリの作成 Directory creation」参照)が導入されたときに廃止されています。directoryタスクのタスク名に、「/」が含まれるためです。

The examples from the last section were special, as the projects had no Execution Dependencies. They had only Configuration Dependencies. The following sections illustrate the differences between these two types of dependencies.

先ほどまでの例は特殊なもので、プロジェクトの間で設定情報は依存関係がありましたが、実行に関しては依存関係がありませんでした。次のセクションでは、これら2つのタイプの依存関係の違いについて説明します。

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
            }
        }
    }
}

What if one project 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 「プロジェクト依存関係 Project dependencies」, Gradle offers project lib dependencies for this.

あるプロジェクトが、別のプロジェクトの生成するjarをコンパイルするときのクラスパスに必要としていたらどうすればいいのでしょう。さらに、単にjarだけでなく、そのjarが依存する他のライブラリも必要だとしたら？ これは、Javaのマルチプロジェクトではいかにもよくありそうなパターンです。「プロジェクト依存関係 Project dependencies」ですでに言及していますが、プロジェクト依存関係はこのようなケースに対応するものです。

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

We have the projects “shared”, “api” and “personService”. The “personService” project has a lib dependency on the other two projects. The “api” project has a lib dependency on the “shared” project. ^[34]

shared、api、personServiceの三つのプロジェクトがあります。personServiceプロジェクトは他の二つのプロジェクトに依存しています。さらに、apiプロジェクトはsharedプロジェクトに依存しています。 ^[35]

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')
    }
}

All the build logic is in the “build.gradle” file of the root project. ^[36] 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 the “shared” project is built and then the “api” project is built. Project dependencies enable partial multi-project builds.

ビルドロジックはすべてルートプロジェクトのbuild.gradleに記述されています。 ^[37] プロジェクト依存関係は、実行依存の別形態といえます。まずあるプロジェクトのビルドを実行し、生成されたクラスをjarに格納して、そのプロジェクトに依存しているプロジェクトのクラスパスに追加するのです。さらに、そのプロジェクトの依存関係も同時にクラスパスに追加します。apiディレクトリに移動して、gradle compileと入力してみましょう。まずsharedがビルドされ、次にapiがビルドされるでしょう。プロジェクト依存はマルチプロジェクトの部分ビルドを可能にします。

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:

Mavenを使用されてきた人なら、このことですごく満足できるでしょう。Ivyの経験をお持ちなら、もっと細かい制御を期待するかもしれません。Gradleでは、次のようにします。

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')
    }
}

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”.

Javaプラグインは、デフォルトではすべてのクラスが含まれたjarをプロジェクトのライブラリとして追加しますが、ここではそれに加えて、apiプロジェクトのインターフェースのみが含まれたライブラリを作成しています。そしてこのライブラリを、新規に作成した、依存関係のコンフィギュレーション(spi)に割り当てています。person serviceをコンパイルするときはインターフェースしか要りませんが、テストをするにはapiからすべてのクラスを持ってくる必要があるのです。

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:

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.

Parallel project execution allows the separate projects in a decoupled multi-project build to be executed in parallel (see also: 「分離されたプロジェクト 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:

How does parallel execution work? First, you need to tell Gradle to use the parallel mode. You can use the command line argument (付録D Gradle コマンドラインGradle Command Line) or configure your build environment (「gradle.propertiesを使用したビルド環境の構築Configuring the build environment via gradle.properties」). Unless you provide a 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 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 effectively prevents Gradle from correctly building multiple projects in parallel, configuring only a subset of projects, or from substituting a pre-built artifact in place of a project dependency.

Gradleでは、評価フェーズでも実行フェーズでも、あらゆるプロジェクト間でお互いにアクセスすることができるようになっています。 これはビルドの作成者にとっては非常に強力で柔軟性のある仕様ですが、ビルド時にはGradleの方の柔軟性が制限されることになります。 例を挙げると、強固に結合されたプロジェクトは、Gradleに平行ビルドさせることができませんし、依存プロジェクトの代わりにビルド済みのアーティファクトを使用することもできません。

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 (「プロジェクト依存関係 Project dependencies」) and/or task dependencies (「タスクの依存関係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. The consequence of coupling during the configuration phase is that if gradle is invoked with the 'configuration on demand' option, the result of the build can be flawed in several ways. The consequence of coupling during execution phase is that if gradle is invoked with the parallel option, one project task runs too late to influence a task of a project building in parallel. Gradle does not attempt to detect coupling and warn the user, as there are too many possibilities to introduce coupling.

お互いのプロジェクト・モデルにアクセスしない二つのプロジェクトは、分離されたプロジェクトと呼ばれます。 分離されたプロジェクトでは、お互いのやりとりに依存関係宣言のみを使用します。つまり、プロジェクト依存(「プロジェクト依存関係 Project dependencies」)やタスク依存(「タスクの依存関係Task dependencies」)です。 その他のあらゆるアクセス、例えば他プロジェクトのオブジェクトを変更したり、設定値を読み込んだりといった処理は、全てプロジェクトを結合させます。

A very common way for projects to be coupled is by using configuration injection (「クロスプロジェクト設定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. Coupling of the root project to subprojects does not impact 'configuration on demand', but using the allprojects and subprojects in any subproject's build.gradle file will have an impact.

プロジェクトが結合されるもっとも一般的な状況は、設定のインジェクション(「クロスプロジェクト設定Cross project configuration」)です。 これは直ぐには分かりにくいかもしれませんが、allprojectsやsubprojectsキーワードのような、Gradleの特定の機能を使うと、プロジェクトは自動的に結合されます。 これらのキーワードは、build.gradleファイルで別のプロジェクトを定義するのに使われるからです。 共通設定の定義しかしていないルートプロジェクトもよくありますが、Gradleがルートプロジェクトを、完全な普通のプロジェクトと判断し、さらにallprojectsを使用している限り、プロジェクトは他の全てのプロジェクトと結合されます。

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.

つまり、どんな形であれ、ビルドスクリプトのロジック共有、および設定のインジェクション(allprojectsやsubprojectsなど)は、プロジェクトを結合させるということです。 私たちは、この分離されたプロジェクトという概念を拡張し、有効活用するような機能を追加する予定です。それにより、設定インジェクションなどの機能を、プロジェクトを結合することなく実現できます。

In order to make good use of cross project configuration without running into issues for parallel and 'configuration on demand' options, follow these recommendations:

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.

Javaプラグインのbuildタスクは、シングルプロジェクトをコンパイル、テスト、さらに(CodeQualityプラグインを使っていれば)コードスタイルのチェックも行うという、典型的なビルド処理を実行します。さらに、マルチプロジェクトを構成している場合は、これらのタスクをプロジェクトを横断して実行したい場面もあるでしょう。buildNeededとbuildDependentsはこの用途を助けてくれるものです。

Let's use the project structure shown in 例57.25「プロジェクト依存関係」. In this example, the “:services:personservice” project depends on both the “:api” and “:shared” projects. The “:api” project also depends on the “:shared” project.

例57.25「プロジェクト依存関係」にあるプロジェクトの構造を使いましょう。この例では:service:personserviceが:apiと:sharedの双方に依存しています。また、:apiは:sharedに依存しています。

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.

シングルプロジェクトの:apiプロジェクトで作業しているとします。:apiに変更を加えましたが、クリーン以降、まだプロジェクト全体のビルドはしていません。jarが必要になってビルドするというとき、コード品質のチェックやユニットテストは自分が変更したプロジェクトでのみ実行したいところです。buildタスクは、まさにこの処理を行います。

> 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

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 building “:shared:compile” 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.

典型的な開発サイクルでは、:apiプロジェクトに何か変更を加えるたびビルドとテストを繰り返すことになります。このとき、:shared:compileタスクは、ビルドのたび:sharedプロジェクトが変更されていないか確認しに行きます。:apiプロジェクトしか変更していないことが分かっている場合、このコストさえ苦痛かもしれません。-aオプションをつけてビルドすると、依存プロジェクトのライブラリを解決する際、キャッシュされたjarが使用されるので、依存プロジェクトが再ビルドされることありません。

> 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

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.

今、ちょうど最新のソースをバージョン管理システムから持ってきたとしましょう。:apiが依存しているプロジェクトが変更されていました。このとき、依存先の全プロジェクトについて、ビルドだけでなくテストもしたいと考えるかもしれません。buildNeededタスクは、指定したプロジェクトだけでなく、そのプロジェクトのtestRuntime依存関係に設定されているプロジェクトをすべてテストします。

> 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

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.

さらに、:apiプロジェクトをリファクタリングする場合のことを考えてみます。:apiプロジェクトは他のプロジェクトから使用されているので、このプロジェクトだけテストしても十分とは言えません。:apiプロジェクトに依存しているすべてのプロジェクトをテストする必要があります。buildDependentsタスクは、指定したプロジェクトだけでなく、そのプロジェクトにtestRuntimeのプロジェクト依存関係を持っているすべてのプロジェクトをテストします。

> 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

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.

最後に、すべてのプロジェクトをビルド、テストしたいと思うことがあるかもしれません。ルートプロジェクトのフォルダーでタスクを実行すれば、全ての子プロジェクトでそのタスクと同名のタスクが実行されます。なので、ただgradle buildと実行すれば大丈夫です。すべてのプロジェクトがビルドされテストされます。

「buildSrcプロジェクトのソースをビルドするBuild sources in the buildSrc project」 tells us that we can place build logic to be compiled and tested in the special buildSrc directory. In a multi project build, there can only be one buildSrc directory which must be located in the root directory.

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.

プロジェクトで宣言されたプロパティとメソッドは、すべての子プロジェクトに継承されます。これは設定のインジェクションの代替手段となるでしょう。ただ、私たちは継承というモデルはマルチプロジェクトの様々な特質を十分に反映できるものではないと考えています。将来バージョンのユーザーガイドでこのことについて詳しく書くつもりです。

Method inheritance might be interesting to use as Gradle's Configuration Injection does not support methods yet (but will in a future release).

なお、Gradleの設定のインジェクションではまだメソッドを注入することができません(将来のリリースで対応する予定です)。なので、メソッドについては継承を使う価値があるかもしれません。

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.

どうみても継承機能を敬遠しているのに、なんでそんなのを実装したのか不思議に思われるかもしれません。一つの理由は、継承機能が別のビルドツールで提供されているからです。比較表にチェックマークを付けたかったのです(^^)。また、ユーザーには選択肢を用意したかったというのもあります。

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. ^[38] With those elements, and keeping in mind that Gradle has a distinct configuration and execution phase, you already have 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.

この章を書くのは非常に疲れました。読むのも疲れるでしょう。最後にひとつだけ、Gradleでマルチプロジェクトを扱うのは決して難しいことではありません。覚えておく必要があるのは次の5つだけです。allproject、subprojects、evaluationDependsOn、evaluationDependsOnChildren、そしてプロジェクト依存関係です。 ^[39] この5つ、そしてGradleが設定フェーズと実行フェーズを別個に取り扱うのだということを覚えておけば、あとは多くの場合融通がききます。もし何らかの困難な問題に突き当たったとしても、Gradleが障害になることもなく、逆にあなたを見晴らしのいい山の上に連れて行ってくれるはずです。