Gradle Task Dependencies and Ordering: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 45: Line 45:
* [https://docs.gradle.org/current/javadoc/org/gradle/api/Task.html#setShouldRunAfter-java.lang.Iterable- Task.setShouldRunAfter(Iterable)]
* [https://docs.gradle.org/current/javadoc/org/gradle/api/Task.html#setShouldRunAfter-java.lang.Iterable- Task.setShouldRunAfter(Iterable)]
==Explicit Dependencies between Tasks belonging to Different Projects==
==Explicit Dependencies between Tasks belonging to Different Projects==
In a multi-project situation, tasks belonging to two different projects can express the dependency on one another by using full task paths:
In a multi-project situation, tasks belonging to two different projects can express the dependency on one another by using [[Gradle_Task#Name_and_Path|task paths]]:
<syntaxhighlight lang='groovy'>
<syntaxhighlight lang='groovy'>
red.dependsOn(':project-a:yellow')
red.dependsOn(':project-a:yellow')

Revision as of 01:45, 22 October 2020

External

Internal

Overview

May times, a task requires another task to run first, especially if the task depends on the produced output of its dependency task. A task may declared its dependencies explicitly. A task may depend on other tasks implicitly, as described in the Implicit Dependencies section.

In Gradle, task execution order is automatically determined taking into account explicit dependencies and implicit dependencies, and a specific execution order of all tasks involved is not guaranteed. The only thing that is guaranteed is that the dependencies will be honored. This architectural decision has several benefits: you don't need to know the whole chain of task dependencies to make a change, and because the tasks don't have to be executed strictly sequentially, they can be parallelized.

If tasks belonging to different sub-projects that are part of the same multi-project define dependencies among themselves, that automatically introduces a dependency between the owning projects:

Multi-project builds | Inter-project Dependencies

Explicit Dependencies

The Task API used to declare explicit task dependencies is Task.dependsOn(Object... paths), which surfaces in the DSL as:

task red {
  dependsOn 'blue', 'green' // comma is required
  ...
}
task red(dependsOn: [blue, green] {
  ...
}
task red {
  ...
}

red.dependsOn(blue, green)

Note that a task dependency may be another task name, the task instance itself or another objects.

If multiple tasks are provides as argument of dependsOn(...), the order in which they are declared does not influence the order in which they are executed. The only thing that is guaranteed is that all will be executed before the task that declares the dependency.

Other methods that can be used to set explicit dependencies are:

Explicit Dependencies between Tasks belonging to Different Projects

In a multi-project situation, tasks belonging to two different projects can express the dependency on one another by using task paths:

red.dependsOn(':project-a:yellow')

This explicit dependency also introduces a dependency between projects, causing dependency project ("project-a") to be configured before the current project in the configuration phase.

Finalizer Tasks

A finalizer task is a task that will be scheduled to run after the task that requires finalization, regardless of whether the task succeeds or fails.

task a { ... }
task b { ... }
a.finalizedBy b

Implicit Dependencies

Implicit dependencies are determined base on task inputs and outputs.