第19章 Gradleデーモン

19.1. デーモン入門 Enter the daemon

The Gradle daemon (sometimes referred as the build daemon) aims to improve the startup and execution time of Gradle.

Gradleデーモン(ビルドデーモンと呼ばれることもあります)はGradleの起動と実行の速度を改善します。

We came up with several use cases where the daemon is very useful. For some workflows, the user invokes Gradle many times to execute a small number of relatively quick tasks. For example: デーモン実行が非常に有用だと思われるユースケースをいくつか考えてみました。例えば、少数の、比較的実行が早く終わるようなタスクを、何度も実行しなければならないような場面があります。

When using test driven development, where the unit tests are executed many times. テスト駆動開発にて、ユニットテストを度々実行するような場合
When developing a web application, where the application is assembled many times. Webアプリケーション開発にて、アプリケーションを何度も構築する場合
When discovering what a build can do, where gradle tasks is executed a number of times. ビルドの挙動を調べるために、gradle tasksを何度も実行する場合

For these workflows, it is important that the startup cost of invoking Gradle is as small as possible. これらの場合、Gradleを起動・実行するための時間は出来る限り短いことが重要でしょう。

In addition, user interfaces can provide some interesting features if the Gradle model can be built relatively quickly. For example, the daemon might be useful for the following scenarios: さらに、Gradleモデルがより素早く構築されるようになれば、ユーザーインターフェースが面白い機能を実装できる可能性があります。例えば、次のようなケースでデーモンが役に立つかもしれません。

Content assistance in the IDE 統合開発環境で入力補完する場合
Live visualisation of the build in a GUI GUIでビルド状況を表示する場合
Tab completion in a CLI コマンドラインインターフェースでのタブ補完する場合

In general, snappy behavior of the build tool is always handy. If you try using the daemon for your local builds, you won't want to go back.

一般的にいって、ビルドツールが軽快に動作して困るということはありません。ローカル環境のビルドでデーモンを試してみてください。デーモンを使わない普通のビルドにはもう戻れなくなるでしょう。

The Tooling API (see Chapter 63, Embedding Gradle) uses the daemon all the time, e.g. you cannot officially use the Tooling API without the daemon. This means that whenever you are using the STS Gradle plugin for Eclipse or the Gradle support in Intellij IDEA, you're already using the Gradle Daemon.

ツールAPI (参照 Chapter 63, Embedding Gradle)は常にデーモンを使用します。つまり、通常、デーモンなしでツールAPIは使えません。したがって、EclipseのSTS GradleプラグインやIntelliJ IDEAのGradleサポートを使っているときは、常にデーモンが背後で起動しています。

In future, there are plans for more features in the daemon: 今後は下記の機能が追加される予定です。

Snappy up-to-date checks: use native file system change notifications (e.g. via jdk7 nio.2) to preemptively perform up-to-date analysis. 軽快な更新チェック: ファイルシステムネイティブの変更通知を(jdk7 nio.2経由などで)使い、プロジェクトが更新されたかどうか前もって解析する
Even faster builds: preemptively evaluate projects, so that the model is ready when the user next invokes Gradle. 更なるビルドの高速化: あらかじめプロジェクトを評価し、次回のGradle実行時にプロジェクトモデルを準備しておく
Did we mention faster builds? The daemon can potentially preemptively download dependencies or check for new versions of snapshot dependencies. 更なるビルドの高速化、はもう言いましたっけ、とにかく、デーモンは潜在的にはあらかじめ依存関係をダウンロードしたり、スナップショットに依存している場合はその最新バージョンをチェックしておくといったことが可能です。
Utilize a pool of reusable processes available for compilation and testing. For example, both the Groovy and Scala compilers have a large startup cost. The build daemon could maintain a process with Groovy and/or Scala already loaded. 再利用可能なプロセスのプールを活用して、コンパイル、テストを実施する。例えばGroovyとScalaコンパイラーの起動にはどちらも多大なコストがかかります。しかし、ビルドデーモンは、GroovyやScalaが既にロードされたプロセスを維持しておくことができます。
Preemptive execution of certain tasks, for example compilation. Quicker feedback. コンパイルなど、ある種のタスクは事前に実行しておく。より早いフィードバックが可能になります。
Fast and accurate bash tab completion. 速くて正確なbash上のタブ補完
Periodically garbage collect the Gradle caches. Gradleキャッシュを定期的にガーベージコレクトする

19.2. デーモンの再利用と期限切れ Reusing and expiration of daemons

The basic idea is that the Gradle command forks a daemon process, which performs the actual build. Subsequent invocations of the Gradle command will reuse the daemon, avoiding the startup costs. Sometimes we cannot use an existing daemon because it is busy or its Java version or jvm arguments are different. For exact details on when exactly a new daemon process is forked read the dedicated section below. The daemon process automatically expires after 3 hours of idle time.

デーモン実行の基本にある考え方は、gradleコマンドがデーモンプロセスを起動して、そのデーモンが実際のビルドを実行するというものです。そうすれば、後続のgradleコマンドがそのデーモンプロセスを再利用でき、起動に掛かるコストを抑えることができます。しかし、既存のデーモンプロセスが使用できないこともあります。例えば、プロセスがビジーだったり、要求されたJavaのバージョンやJVM引数が違うといった場合です。新しいデーモンプロセスが、正確にはいつ起動されるかの詳細については、以下を参照してください。デーモンプロセスは、アイドル状態で3時間経過すると自動的に期限切れになります。

Here are all situations in which we fork a new daemon process: デーモンプロセスが新しく起動される場面を全て列挙すると、

If the daemon process is currently busy running some job, a brand new daemon process will be started. 既存のデーモンがある処理を実行中の場合、新たなデーモンが起動されます。
We fork a separate daemon process per Java home. So even if there is some idle daemon waiting for build requests but you happen to run a build with a different Java home then a brand new daemon will be forked. デーモンプロセスは、java homeごとに起動されます。アイドル状態のデーモンがビルドリクエストを待機していたとしても、別のjava homeからビルドを実行した場合デーモンプロセスが新しく起動されます。
We fork a separate daemon process if the jvm arguments for the build are sufficiently different. For example we will not fork a new daemon if a some system property has changed. However if the -Xmx memory setting changed or some fundamental immutable system property changed (e.g. file.encoding) then a new daemon will be forked. ビルドのJVM引数が大きく異なる場合、デーモンプロセスが新しく起動されます。いくつかのシステムプロパティに関しては、変更されても新プロセスを立ち上げないこともあります。しかし、-Xmxメモリ設定や、その他の基本的で変更できないシステムプロパティ(file.encodingなど)が変更された場合、プロセスが新しく起動されます。
At the moment the daemon is coupled with a particular version of Gradle. This means that even if some daemon is idle but you are running the build with a different version of Gradle, a new daemon will be started. This also has a consequence for the --stop command line instruction: this command will only stop daemons that were started with Gradle version that is executing --stop. 起動されているデーモンは、特定のバージョンのGradleと関連づいています。そのため、アイドル状態のデーモンが存在したとしても、それと別のバージョンのGradleでビルドを実行すると新しいデーモンが起動されます。これは、--stopコマンドについてあることを教唆しています――つまり、--stopで停止できるデーモンは、その--stopを実行しているGradleと同じバージョンのGradleで起動されたデーモンだけだということです。

We plan to improve the functionality of managing and pooling the daemons in the future. 今後、デーモンの管理方法、プール方法の改善を行う予定です。

19.3. 使い方とトラブルシューティング Usage and troubleshooting

For command line usage, look at the dedicated section in 付録D Gradle コマンドラインGradle Command Line. If you are tired of using the same command line options again and again, take a look at 「gradle.propertiesを使用したビルド環境の構築Configuring the build environment via gradle.properties」. This section contains information on how to configure certain behavior of the daemon (including turning on the daemon by default) in a more 'persistent' way.

コマンドラインの利用方法については別節付録D Gradle コマンドラインGradle Command Lineを参照してください。同じコマンドラインを何度も何度も指定してうんざりしている場合は、「gradle.propertiesを使用したビルド環境の構築Configuring the build environment via gradle.properties」を参照してください。上記の節には、デーモンの振る舞いをより「永続的に」設定する方法が(デフォルトでデーモンを起動する方法を含めて)詳細に記述されています。

Some ways of troubleshooting the Gradle daemon: デーモンのトラブルシューティングについていくつか方法を示します。

If you have a problem with your build, try temporarily disabling the daemon (you can pass the command line switch --no-daemon). ビルドで問題が発生した場合、一時的にデーモンを無効化してみてください(コマンドラインにスイッチ--no-daemonを渡す)。
Occasionally, you may want to stop the daemons either via the --stop command line option or in a more forceful way.--stopオプションや、もっと強制的な方法でデーモンを停止しなければならない場面もあります。
There is a daemon log file, which by default is located in the Gradle user home directory. デーモンのログファイルは、デフォルトではGradleユーザーホームディレクトリーにあります。
You may want to start the daemon in --foreground mode to observe how the build is executed. ビルドの実行状況を見るには、--feoregroundを使ってデーモンを起動します。

19.4. デーモンの設定 Configuring the daemon

Some daemon settings, such as JVM arguments, memory settings or the Java home, can be configured. Please find more information in 「gradle.propertiesを使用したビルド環境の構築Configuring the build environment via gradle.properties」

デーモン設定のうち、JVM引数、メモリーの設定、Java homeなどは設定ファイルなどで変更できます。詳細については「gradle.propertiesを使用したビルド環境の構築Configuring the build environment via gradle.properties」を参照してください。