Lifecycle and Execution Model

The configuration phase runs every build and configures all tasks. Configuration Avoidance (tasks.register) defers a task's configuration until something actually needs it, so unused tasks are never configured.

Gradle evaluates every project's build script top to bottom, running the build-script code to register and configure tasks. The output is the task model — the set of tasks Gradle knows about and how they depend on each other.

Execution is the third (last) phase. Gradle runs the @TaskAction methods of the selected tasks in dependency order. Configuration, the earlier phase, only builds task objects and wires their dependencies — it does no actual work.

Initialization runs first: Gradle evaluates settings.gradle(.kts) to learn which projects exist (via include), then creates a Project object for each. Configuration runs next, executing each project's build.gradle to register tasks.

It's a directed acyclic graph (DAG) of the tasks Gradle will run for the requested build, ordered by their dependencies. Gradle builds it after the configuration phase finishes and before execution starts.

Register a callback with gradle.buildFinished { result -> ... }. It runs once the build ends and gives you a BuildResult with result.failure, so you can do cleanup or reporting whether the build passed or failed.

The configuration phase is when Gradle reads every project's build script and registers tasks (but doesn't run them). Project evaluation hooks like afterEvaluate run at the tail of this phase, right after a project's script has been read.

Make the service implement AutoCloseable. Gradle calls close() automatically when the build finishes, so you can stop a server or flush a buffer there. You never call close() yourself.

A BuildService is an object Gradle creates lazily and shares across tasks in a build. It holds state (a counter, a connection pool) safely, lives for the whole build, and Gradle closes it at build end.

afterEvaluate registers a callback that runs after a project's build script has finished being evaluated. You use it when your logic depends on values (like extension properties) that are only set later in that script.

Continuous build runs gradle -t <task> (or --continuous). Gradle stays alive, watches the task inputs, and automatically re-runs the requested tasks whenever a relevant input file changes, instead of exiting after one run.

gradle dependencies prints the resolved dependency trees for each configuration. Use --configuration <name> (e.g. runtimeClasspath) to limit the output to one configuration instead of dumping every one.

Use -x or --exclude-task with the task name, e.g. gradle build -x test. Gradle removes that task — and any task needed only by it — from the execution graph for this run.

Use --quiet (-q) for less output, --info (-i) for more, and --debug (-d) for everything. They set the log level; only one applies, with --debug the most verbose and --quiet the least.

-P sets a Gradle project property, read via project.property("name"). -D sets a JVM system property, read via System.getProperty("name"). -P is Gradle-specific; -D is standard JVM.

The Gradle client looks for an idle, compatible daemon already running. If it finds one, it reuses it; otherwise it spawns a fresh daemon process and connects to that.

The Gradle Daemon is a long-lived background JVM that stays running between builds. Your gradle command is a thin client that hands the build to it. It speeds up builds by reusing a warm, already-started JVM instead of starting a fresh one each time.

Run gradle --status to list daemons and their state, and gradle --stop to gracefully stop all idle and compatible daemons started by the current Gradle version.

Compatibility is mainly about the JVM: the daemon must use the same Java home (JAVA_HOME) and have JVM arguments that satisfy the request. The Gradle version must also match.

Every gradle run has two parts: a short-lived client that parses arguments and forwards the build request, and a long-lived daemon JVM that actually runs the build. The client streams console output back; the daemon does the work and stays alive afterward.