Gradle 1.12 Translation-19th chapter. Gradle Daemon Process

For other translated chapters, follow the items on GitHub: https://github.com/msdx/gradledoc/tree/1.12, or visit: http://gradledoc.qiniudn.com/1.12/ Userguide/userguide.html

This article original, reproduced please indicate the source: http://blog.csdn.net/maosidiaoxian/article/details/41343615

My translation of Gradle is subject to the project on GitHub and the documentation on http://gradledoc.qiniudn.com. Where the translation is found to be wrong, the above two places will be updated first. Due to time and energy issues, the translation published in the blog is basically not synchronized changes.

19th Chapter. Gradle Daemon 19.1. Step into the daemon process

Gradle Daemon Process(sometimes also calledBuild Daemons) is designed to improve the start-up and execution time of Gradle.

We have prepared a few use cases that are very useful for daemon processes. For some workflows, the user calls Gradle multiple times to perform a small amount of relatively fast tasks. As an example:

• When you use test-driven development, unit tests are executed multiple times.
• When developing a Web application, the application is assembled multiple times.
• When discovering what a build can do, gradle tasks where it will be executed multiple times.

For each of these workflows, it is important to make the startup cost of calling Gradle as small as possible.

Also, if you can build a Gradle model relatively quickly, the user interface can provide some interesting features. For example, the daemon might be used for the following scenarios:

• content in the IDE help
• Real-time visualization in the GUI constructs the
• Tab key in CLI complete

In general, the agile behavior of building tools can always be useful. If you try to use daemons in your local build, it will make it hard for you to get back to normal Gradle use.

The tooling API (see Chapter 62nd, embedding Gradle ) uses daemons throughout the process. For example, you cannot formally use the tooling API when there is no daemon. This means that when you use STS Gradle in Eclipse or use Gradle support in Intellij idea, you are already using the Gradle daemon.

In the future, the daemon will also provide additional functionality:

• Agile up-to-date check: Use the local file system to modify notifications (for example, by Jdk7 nio.2) to pre-perform up-to-date analysis.
• Faster builds: Pre-evaluation projects so that when users next call Gradle, the model is ready.
• Did we mention a faster build? Daemons can pre-download dependencies or check for new versions of snapshot dependencies.
• Use a reusable thread pool that can be used for compilation and testing. For example, the compiler startup overhead for Groovy and Scala is significant. The build daemon can maintain a downloaded Groovy and/or Scala process.
• Perform certain tasks beforehand, such as compiling. Faster feedback.
• Quick and accurate Bash tab is complete.
• Gradle periodic garbage collection of the cache.

19.2. Reuse and Invalidation daemons

The basic idea is that the Gradle command will fork a daemon to perform the actual build. Subsequent calls to the Gradle command will reuse the daemon to avoid startup overhead. Sometimes we cannot use an existing daemon because it is busy or its Java version or JVM parameters are different. For details on fork a completely new daemon, please read the following topic. The daemon will automatically expire after 3 hours of inactivity.

Here are all the cases where we fork a new daemon:

• If the daemon is currently busy running some jobs, a completely new daemon is launched.
• For each Java home, we fork a separate daemon. So even if there are idle daemons waiting for the build request, but you happen to run the build through a different Java HOME, then a completely new daemon will be forked.
• If the parameters used to build the JVM are sufficiently different, we'll fork a separate daemon. For example, if some system properties have changed, we will not fork a new daemon. However, if the-XMX memory settings change, or if some basic immutable system properties change (for example, file.encoding), the new daemon will be forked.
• at this moment, the daemon is added to the specific version number of Gradle. This means that even if some daemons are idle, but you are running a different build than Gradle, a new daemon will be launched. This also has a kind of --stop command-line directive results: When running --stop , you can only stop daemons that start with your gradle version.

We plan to improve the managing/pooling approach to the daemon in the future.

19.3. Usage and troubleshooting

For command line usage, take a look at the special Appendix D, Gradle command line . If you're tired of using the same command-line options repeatedly, you can look at section 20.1, "Configuring the Build environment with Gradle.properties." This section contains information about how to configure certain behaviors in a "persistent" manner, including by default, to open daemons.

Here are some aspects of troubleshooting the Gradle daemon:

• If you have a problem with your build, try temporarily disabling the daemon (you can do this by using the command-line switch --no-daemon ).
• Sometimes, you may want to --stop stop the daemon through command-line options or more forcefully.
• By default, the Gradle user home directory has a daemon log file.
• You might want to --foreground start the daemon in a pattern to see how the build is performing.

19.4. Configure the Daemon

You can configure settings for some daemons, such as JVM parameters, memory settings, or the Java home directory. For more information, see section 20.1, "Configuring the Build environment with Gradle.properties"

Gradle 1.12 Translation-19th chapter. Gradle Daemon Process