Gradle Daemon No Longer Experimental

(Hans Dockter) #1

summary: Polishing the Gradle build daemon and marking it as no longer experimental. status: Ironing out the remaining issues. Some of the fixes will be available in M5.

code: completed

The daemon is crucial to make Gradle a highly responsive build system. The startup and initialization time of any of the new major JVM languages is significant. As Gradle is based on Groovy, it is also suffering those delays. The solution to this is the Gradle daemon which provides a long running pre-initialized JVM to avoid the startup time.

Having a long running Gradle agent will give us a tool to do many more optimizations in the future (e.g. pre-fetching snapshot dependencies). For now, we need to make it production ready. You can already opt-in to have the daemon enabledvia the –daemon flag at the CLI or in the GRADLE_OPTS environment variable. Several Gradleware team members and I have worked with this option enabled for the last 6 months. But you might run sometimes into issues such as with file-locks under Windows. Then you have to manually kill the daemon process.

(Eric Wendelin) #2

Is there any plan to have the gradle daemon inherit parts of it’s environment?

For example, I can’t execute git within a gradle build when the daemon is turned on because it’s a totally separate environment.

(Merlyn Albery-Speyer) #3

@eric Yes. It’s already in the latest and greatest - although I haven’t tried it myself.

“… The daemon now runs the build using the client’s working directory, environment variables and system properties. …”