Gradle1.12 translation-Chapter 1. Gradle daemon

. The purpose of entering the Gradle Daemon (sometimes called building daemon) of the Daemon is to improve the start time and execution time of Gradle. We have prepared several very useful use cases for the daemon. For some workflows, you can call Gradle multiple times to execute a small number of relatively fast tasks. For example, a unit test is executed multiple times when a test-driven development is used. When developing a web application

For other translated chapters, follow the Github project: Release

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

For my translations of Gradle, refer to the project on Github and documents on the http://gradledoc.qiniudn.com. If any translation error is found, it will be updated in the above two places first. Due to time and energy problems, the translations published in the blog are basically not modified simultaneously.

Chapter 2. Gradle daemon 19th. entering daemon

Gradle daemon(Sometimes calledBuild a daemon) To improve the start time and execution time of Gradle.

We have prepared several very useful use cases for the daemon. For some workflows, you can call Gradle multiple times to execute a small number of relatively fast tasks. For example:

• When a test-driven development is used, the unit test is executed multiple times.
• When developing a web application, the application will be assembled multiple times.
• When you discover what a build can dogradle tasksWhere is the execution performed multiple times.

For the preceding workflows, it is important to minimize the startup cost of calling Gradle.

In addition, if you can build the Gradle model relatively quickly, the user interface can provide some interesting functions. For example, the Daemon may be used in the following scenarios:

• Content help in IDE
• Real-time visual construction in GUI
• The tab key in CLI is complete.

In general, the agile behavior of building tools can always come in handy. If you try to use the daemon in your local build, it will make it hard for you to return to the normal Gradle.

Tooling API (see Chapter 62nd,Embedded Gradle) The daemon process is used throughout the process. For example, you cannot officially use the Tooling API without a daemon. This means that when you use STS Gradle in Eclipse or Gradle support in Intellij IDEA, you are already using the Gradle daemon.

In the future, the Daemon will provide more functions:

• Agile up-to-date check: Pre-execute up-to-date analysis using the local file system modification notification (for example, through jdk7 nio.2.
• Faster building: pre-evaluation project, so that when the user calls Gradle, the model is ready.
• Did we mention faster building? The daemon 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 of Groovy and Scala is very high. Build a daemon to maintain a downloaded Groovy and/or Scala process.
• Execute some tasks in advance, such as compiling. Faster feedback.
• Quick and accurate bash tab key completion.
• Gradle caches regular garbage collection.

19.2. reuse and invalid daemon

The basic idea is that the gradle command fork a daemon to execute 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 about a completely new daemon of fork, refer to the following topics. The daemon will automatically expire three hours after being idle.

Here are all the situations of a new daemon in fork:

• If the daemon is busy running some jobs, a new daemon will be started.
• For each java home, we fork a separate daemon. So even if some idle daemon wait for the build request, but you happen to run the build through different java HOME, a new daemon will be fork.
• If the jvm parameters used for building are different enough, we will fork a separate daemon. For example, if some system properties have been changed, we will not fork a new daemon. However, if the-Xmx memory settings have been changed, or some basic unchanged system properties have been changed (for example, file. encoding), the fork daemon will be created.
• At this moment, the Daemon will be added with a specific version number of Gradle. This means that even if some daemon are idle, a new daemon will be started even if the build you are running is different from the Gradle version. This also has--stopCommand line command result: when running--stopYou can only stop daemon started in your Gradle version.

We plan to improve the management/pooling method of the daemon in the future.

19.3. usage and troubleshooting

For usage of command lines, see Appendix D of the topic,Gradle command line. If you are tired of repeatedly using the same command line options, you can refer to section 20.1, "configure the build environment through gradle. properties ". This section contains information about how to configure certain behaviors (including opening Daemon by default) in a "persistent" manner.

The following are some troubleshooting aspects of the Gradle daemon:

• If there is a problem with your build, try to temporarily disable the Daemon (you can use the command line switch--no-daemon).
• Sometimes, you may want--stopCommand line options or a more powerful way to stop the daemon.
• By default, there is a daemon log file in the Gradle user's home directory.
• You may want--foregroundTo observe how the build is executed.

19.4. configure the daemon

You can configure some daemon settings, such as JVM parameters, memory settings, or the Java home directory. For more information, see Section 20.1, "configure the build environment through gradle. properties"