Task Dependencies & Ordering

finalizedBy declares that a finalizer task must run after a given task, even if that task fails. It's used for cleanup or teardown work, like releasing resources or generating a report after tests.

Run the build with the --dry-run (-m) flag, e.g. gradle build --dry-run. Gradle resolves and prints the full task execution order with each task marked SKIPPED, but executes nothing.

An ordering rule only fixes the relative order of two tasks IF both already end up in the task graph. It never adds a task to the graph or forces it to run, unlike a dependency, which both pulls a task in and runs it first.

You can pass a task name string, a Task or TaskProvider reference, a Provider, a Collection, or a closure. A TaskProvider is preferred because it is lazy — it doesn't force the other task to be created/configured eagerly.

dependsOn pulls a task in to run before; mustRunAfter/shouldRunAfter only constrain ordering when both tasks are already in the graph. finalizedBy schedules a task to run after — even on failure — for cleanup.

Gradle cannot order a cycle, so it fails the build with a 'Circular dependency between the following tasks' error listing the tasks in the cycle. It detects this during graph resolution, before executing anything.

Gradle starts from the requested tasks, transitively pulls in all their dependencies into a directed acyclic graph (DAG), then topologically sorts that graph so every task runs after the tasks it depends on.

layout.buildDirectory is a DirectoryProperty provider. Deriving a producer's output from it gives a lazy, relocatable location; consuming that same provider downstream lets Gradle infer the dependency instead of using a hardcoded path with dependsOn.

If one task's input is wired to another task's output Provider, Gradle automatically runs the producer first. You never call dependsOn — the dependency is implied by the data wiring itself.

mustRunAfter is a hard ordering constraint that Gradle always honors when both tasks run. shouldRunAfter is best-effort: Gradle tries to honor it but silently drops it if honoring it would create an ordering cycle (or conflict with a real dependency).

Pass several arguments to one dependsOn call, call dependsOn multiple times, or pass a collection — dependencies accumulate. A custom aggregate is an empty task that dependsOn the real tasks, grouping them under one command.

A finalizer runs after its finalized task whenever that task actually starts executing — success or failure. If the finalized task never executes (e.g. a prerequisite failed, or it isn't in the graph), the finalizer does not run.

A task's outputs (task.outputs.files) form a FileCollection that is built-by that task. Passing it as another task's input — e.g. inputs.files(producer) — makes Gradle infer the dependency, even without referencing a named output property.

mustRunAfter only orders tasks that are already scheduled; it never adds build to the graph. Running gradle release alone won't build. They need a real dependency (release.dependsOn(build)) or to request both tasks.

After configuration, Gradle takes the requested tasks, transitively follows dependsOn edges to gather every needed task, builds a directed acyclic graph, topologically sorts it, then executes — running parallel branches concurrently when enabled.

Have the test task dependsOn a setup task and finalizedBy a teardown task, so teardown runs even on test failure. Guard against teardown not running when setup fails, idempotent teardown, and configuration-cache compatibility.

Gradle merges all requested tasks into a single DAG, deduplicates shared dependencies (each task runs once), and topologically sorts the whole thing. -x <task> removes that task and any edge into it from the plan, so it and its now-unneeded dependencies are excluded.

The task graph is the DAG of tasks Gradle will execute (e.g. compile before test). The dependency/artifact graph is the resolved tree of external modules/jars for a configuration (e.g. via dependencies). They are separate concepts solving separate problems.

Usually the provider link was severed — someone called .get() while configuring, used a plain File, or left the input un-annotated. Restore lazy provider wiring (map/flatMap on the producer's output property) and the dependency re-infers; avoid patching with dependsOn.

Use map when the transform returns a plain value, flatMap when it returns another Provider. Both keep the producer task attached, so the inferred dependency survives. Avoid .get(), which resolves eagerly and drops the producer link.

Prefer passing TaskProviders or task names to mustRunAfter/shouldRunAfter and configure inside tasks.named { }, so you don't eagerly realize tasks at configuration time. Eagerly resolving with tasks.getByName(...) forces unnecessary task creation and hurts configuration performance.

Ordering rules only constrain relative order between the two named tasks; tasks with no ordering or dependency edge between them may run in parallel and in non-deterministic order. Use mustRunAfter/shouldRunAfter to force a specific sequence where it matters without making one task depend on the other.

dependsOn only orders and includes tasks; it doesn't wire outputs to inputs. Over-using it for data flow leads to missing dependencies, broken incremental builds and cache misses, and a brittle hand-maintained graph.

Finalization is one-directional: requesting a finalizer never pulls in its finalized task. But combining finalizedBy with dependsOn carelessly can create a true cycle, which Gradle rejects with a circular-dependency error.

Use gradle.taskGraph.whenReady { graph -> } (or graph.hasTask(...)). It fires after the full task graph is resolved but before execution, so logic can branch on whether, say, a release task is in the plan.

Yes — a provider from another project's task carries that task as producer, so consuming it infers a cross-project dependency. The clean way to expose outputs across modules is via variant-aware configurations (consumable/resolvable) rather than reaching into another project's tasks.