// Copyright (C) 2023 Gradle, Inc.
//
// Licensed under the Creative Commons Attribution-Noncommercial-ShareAlike 4.0 International License.;
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//      https://creativecommons.org/licenses/by-nc-sa/4.0/
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

[[task_configuration_avoidance]]
= Task Configuration Avoidance

This chapter provides an introduction to "configuration avoidance" when dealing with tasks and explains some guidelines for migrating your build to use the configuration avoidance APIs effectively. The API described here co-exists with an existing API that will be replaced with our usual deprecation process over several major releases.  As of Gradle 5.1, we recommend that the configuration avoidance APIs be used whenever tasks are created by custom plugins.

[[sec:how_does_it_work]]
== How does the configuration avoidance API work?

In a nutshell, the API allows builds to avoid the cost of creating and configuring tasks during Gradle's configuration phase when those tasks will never be executed.
For example, when running a `compile` task, other unrelated tasks (such as `clean`, `test`, `javadocs`) will not be executed.

The configuration avoidance API avoids configuring tasks if they will not be needed during the course of a build, which can have a significant impact on total configuration time.

To avoid creating and configuring tasks, we say that a task is "registered" but not created.  When a task is in this state, it is known to the build, it can be configured, and references to it can be passed around, but the task object itself has not actually been created, and none of its configuration actions have been executed.  It will remain in this state until something in the build needs the instantiated task object (for instance if the task is executed on the command line or the task is a dependency of a task executed on the command line).  If the task object is never needed, then the task will remain in the registered state, and the cost of creating and configuring the task will be avoided.

In Gradle, you register a task using link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-[TaskContainer.register(java.lang.String)]. There are variations of this method that allow providing a task type and/or an action for modifying the task configuration. Instead of returning a task instance, the `register(...)` method returns a link:{javadocPath}/org/gradle/api/tasks/TaskProvider.html[TaskProvider], which is a reference to the task that can be used in many places where a normal task object might be used (for example when creating task dependencies).

[[sec:task_configuration_avoidance_guidelines]]
== Guidelines

[[sec:how_do_i_defer_creation]]
=== How do I defer task creation?

Effective task configuration avoidance requires build authors to change instances of link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.lang.String-[TaskContainer.create(java.lang.String)] to link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-[TaskContainer.register(java.lang.String)].

Older versions of Gradle only support the `create(...)` API. The `create(...)` API eagerly creates and configures tasks when it is called and should be avoided.

Using `register(...)` alone may not be enough to avoid all task configuration completely. You may need to change other code that configures tasks by name or by type, as explained in the following sections.

[[sec:how_do_i_defer_configuration]]
=== How do I defer task configuration?

Eager APIs like link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#all-org.gradle.api.Action-[DomainObjectCollection.all(org.gradle.api.Action)] and link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#withType-java.lang.Class-org.gradle.api.Action-[DomainObjectCollection.withType(java.lang.Class, org.gradle.api.Action)] will immediately create and configure any registered tasks. To defer task configuration, you will need to migrate to a configuration avoidance API equivalent. See the <<#sec:old_vs_new_configuration_api_overview,table below>> to identify the alternative.

[[sec:how_do_i_reference_a_task]]
=== How do I reference a task without creating/configuring it?

Instead of referencing a task object, you can work with a registered task via a link:{javadocPath}/org/gradle/api/tasks/TaskProvider.html[TaskProvider] object.  A link:{javadocPath}/org/gradle/api/tasks/TaskProvider.html[TaskProvider] can be obtained in several ways including when calling link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-[TaskContainer.register(java.lang.String)] or using the link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#named-java.lang.String-[TaskCollection.named(java.lang.String)] method.

Calling link:{javadocPath}/org/gradle/api/provider/Provider.html#get--[Provider.get()] or looking up a task by name with link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#getByName-java.lang.String-[TaskCollection.getByName(java.lang.String)] will cause the task to be created and configured. Methods like link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:dependsOn(java.lang.Object++[]++)[Task.dependsOn(java.lang.Object...)] and link:{javadocPath}/org/gradle/api/file/ConfigurableFileCollection.html#builtBy-java.lang.Object++...++-[ConfigurableFileCollection.builtBy(java.lang.Object++...++)] work with link:{javadocPath}/org/gradle/api/tasks/TaskProvider.html[TaskProvider] in the same way as link:{groovyDslPath}/org.gradle.api.Task.html[Task], so you do not need to unwrap a `Provider` for explicit dependencies to continue to work.

If you are configuring a task by name, you will need to use the configuration avoidance equivalent. See the <<#sec:old_vs_new_configuration_api_overview,table below>> to identify the alternative.

[[sec:how_do_i_get_a_task]]
=== How to get an instance of a Task?

In the event you still need to get access to a Task instance, you can use link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#named-java.lang.String-[TaskCollection.named(java.lang.String)] and call link:{javadocPath}/org/gradle/api/provider/Provider.html#get--[Provider.get()].  This will cause the task to be created/configured, but everything should work as it has with the eager APIs.

[[sec:how_do_i_order_tasks]]
=== How do I order tasks with configuration avoidance in mind?

[NOTE]
====
Calling ordering methods will not cause task creation by itself.
All these methods do is declare relationships.
However, it's important to note, that the existence of these relationships might indirectly cause task creation in later stages of the build process.
====

When task relationships need to be established (i.e. `dependsOn`, `finalizedBy`, `mustRunAfter`, `shouldRunAfter`), a distinction can be made between soft, and strong relationships, as their effects on task creation in configuration time differ:

link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:mustRunAfter(java.lang.Object++[]++)[Task.mustRunAfter(...)] and link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:shouldRunAfter(java.lang.Object++[]++)[Task.shouldRunAfter(...)] represent soft relationships, which can only change the order of existing tasks, but can't trigger their creation.

link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:dependsOn(java.lang.Object++[]++)[Task.dependsOn(...)] and link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:finalizedBy(java.lang.Object++[]++)[Task.finalizedBy(...)] represent strong relationships, which will _force_ the execution of referenced tasks, even if they wouldn't have been created otherwise.

- If a task is _not_ executed (regardless if it was created with link:{groovyDslPath}/org.gradle.api.tasks.TaskContainer.html#org.gradle.api.tasks.TaskContainer:register(java.lang.String)[Task.register(...)] or link:{groovyDslPath}/org.gradle.api.tasks.TaskContainer.html#org.gradle.api.tasks.TaskContainer:create(java.lang.String)[Task.create(...)]), the defined relationships will not trigger any task creation at configuration time.
- If a task _is_ executed, all strongly associated tasks need to be created and configured at configuration time, as they might have other `dependsOn` or `finalizedBy` relationships. This will happen transitively, until the task graph contains all strong relationships.

[[sec:task_configuration_avoidance_migration_guidelines]]
== Migration Guide

The following sections will go through some <<#sec:task_configuration_avoidance_general, general guidelines>> to adhere to when migrating the build logic as well as <<#sec:task_configuration_avoidance_migration_steps, the steps>> we recommend following.
We also cover some <<#sec:task_configuration_avoidance_troubleshooting, troubleshooting>> and <<#sec:task_configuration_avoidance_pitfalls, pitfalls>> to help you work around some issues you may encounter during the migration.

[[sec:task_configuration_avoidance_general]]
=== General
1. [[task_configuration_avoidance_guideline_use_help_task]] **Use `help` task as a benchmark during the migration.**
The `help` task is the perfect candidate to benchmark your migration process.
In a build that uses only the configuration avoidance API, https://scans.gradle.com/s/o7qmlmmrsfxz4/performance/configuration?openScriptsAndPlugins=WzFd[a build scan would show no tasks created immediately or created during configuration], and only the tasks that were actually executed would be created.
Be mindful of <<#task_configuration_avoidance_pitfall_build_scan_plugin, the version of the build scan plugin in use>>.

2. [[task_configuration_avoidance_guideline_only_mutate_task_object]] **Only mutate the current task inside a configuration action.**
Because the task configuration action can now run immediately, later or never, mutating anything other than the current task can cause indeterminate behavior in your build.
Consider the following code:
+
====
[.multi-language-sample]
=====
[source,kotlin]
----
val check by tasks.registering
tasks.register("verificationTask") {
    // Configure verificationTask

    // Run verificationTask when someone runs check
    check.get().dependsOn(this)
}
----
=====
[.multi-language-sample]
=====
[source,groovy]
----
def check = tasks.register("check")
tasks.register("verificationTask") { verificationTask ->
    // Configure verificationTask

    // Run verificationTask when someone runs check
    check.get().dependsOn verificationTask
}
----
=====
====
Executing the `gradle check` task should execute `verificationTask`, but with this example, it won't.
This is because the dependency between `verificationTask` and `check` only happens when `verificationTask` is realized.
To avoid issues like this, you must only modify the task associated with the configuration action.
Other tasks should be modified in their own configuration action.
The code would become:
+
====
[.multi-language-sample]
=====
[source,kotlin]
----
val check by tasks.registering
val verificationTask by tasks.registering {
    // Configure verificationTask
}
check {
    dependsOn(verificationTask)
}
----
=====
[.multi-language-sample]
=====
[source,groovy]
----
def check = tasks.register("check")
def verificationTask = tasks.register("verificationTask") {
    // Configure verificationTask
}
check.configure {
    dependsOn verificationTask
}
----
=====
====
In the future, Gradle will consider this sort of anti-pattern an error and will produce an exception.

3. [[task_configuration_avoidance_guideline_prefer_small_incremental_change]] **Prefer small incremental changes.**
Smaller changes are easier to sanity check.
If you ever break your build logic, it will be easier to analyze the changelog since the last successful verification.

4. [[task_configuration_avoidance_guideline_validate_build_logic]] **Ensure a good plan is established for validating the build logic.**
Usually, a simple `build` task invocation should do the trick to validate your build logic.
However, some builds may need additional verification — understand the behavior of your build and make sure you have a good plan for verification.

5. [[task_configuration_avoidance_guideline_prefer_automatic_testing]] **Prefer automatic testing to manual testing.**
It’s good practice to write integration test for your build logic using TestKit.

6. [[task_configuration_avoidance_guideline_avoid_task_by_name]] **Avoid referencing a task by name.**
In the majority of cases, referencing a task by name is a fragile pattern and should be avoided.
Although the task name is available on the `TaskProvider`, effort should be made to use references from a strongly typed model instead.

7. **Use the new task API as much as possible.**
Eagerly realizing some tasks may cause a cascade of other tasks to be realized.
Using `TaskProvider` helps create an indirection that protects against transitive realization.

8. Some APIs may be disallowed if you try to access them from the new API's configuration blocks. For example,
link:{groovyDslPath}/org.gradle.api.Project.html#org.gradle.api.Project:afterEvaluate(org.gradle.api.Action)[`Project.afterEvaluate()`]
cannot be called when configuring a task registered with the new API. Since `afterEvaluate` is used to delay configuring a `Project`, mixing delayed configuration
with the new API can cause errors that are hard to diagnose because tasks registered with the new API are not always configured, but an `afterEvaluate` block
may be expected to always execute.

[[sec:task_configuration_avoidance_migration_steps]]
=== Migration Steps
The first part of the migration process is to go through the code and manually migrate eager task creation and configuration to use configuration avoidance APIs.
The following explores the recommended steps for a successful migration.
While going through these steps, keep in mind <<#sec:task_configuration_avoidance_general, the guidelines>> above.

NOTE: Using the new API in a plugin will require users to use Gradle 4.9 or later. Plugin authors should refer to <<#sec:task_configuration_avoidance_backward_compatibility_migration>> section.

1. **Migrate task configuration that affects all tasks (`tasks.all {}`) or subsets by type (`tasks.withType(...) {}`).**
This will cause your build to eagerly create fewer tasks that are registered by plugins.

2. **Migrate tasks configured by name.**
Similar to the previous point, this will cause your build to eagerly create fewer tasks that are registered by plugins.
For example, logic that uses `TaskContainer#getByName(String, Closure)` should be converted to `TaskContainer#named(String, Action)`.
This also includes <<#task_configuration_avoidance_pitfalls_hidden_eager_task_realization, task configuration via DSL blocks>>.

3. **Migrate tasks creation to `register(...)`.**
At this point, you should change anywhere that you are creating tasks to instead register those tasks.


For all steps above, be aware of the <<#sec:task_configuration_avoidance_pitfalls, common pitfalls around deferred configuration>>.

After making these changes, you should see improvement in the number of tasks that are eagerly created at configuration time.  Use <<#sec:task_configuration_avoidance_troubleshooting, build scans>> to understand what tasks are still being created eagerly and where this is happening.

[[sec:task_configuration_avoidance_troubleshooting]]
=== Troubleshooting
* **What tasks are being realized?**
As we keep developing the feature, more reporting, and troubleshooting information will be made available to answer this question.
In the meantime, https://gradle.com/enterprise/releases/2018.3#reduce-configuration-time-by-leveraging-task-creation-avoidance[build scan is the best way to answer this question].
Follow these steps:

  a. https://scans.gradle.com/[Create a build scan].
  Execute the Gradle command using the `--scan` flag.

  b. Navigate to the configuration performance tab.
+
.Navigate to configuration performance tab in build scan
image::taskConfigurationAvoidance-navigate-to-performance.png[]
+
    1. Navigate to the performance card from the left side menu.
    2. Navigate to the configuration tab from the top of the performance card.

  c. All the information requires will be presented.
+
.Configuration performance tab in build scan annotated
image::taskConfigurationAvoidance-performance-annotated.png[]
+
    1. Total tasks present when each task is created or not.
      - "Created immediately" represents tasks that were created using the eager task APIs.
      - "Created during configuration" represents tasks that were created using the configuration avoidance APIs, but were realized explicitly (via `TaskProvider#get()`) or implicitly using the eager task query APIs.
      - Both "Created immediately" and "Created during configuration" numbers are considered the "bad" numbers that should be minimized as much as possible.
      - "Created during task graph calculation" represents the tasks created when building the execution task graph.
      Ideally, this number would be equal to the number of tasks executed.
      - "Not created" represents the tasks that were avoided in this build session.

    2. The next section helps answer the question of where a task was realized. For each script, plugin or lifecycle callback, the last column represents the tasks that were created either immediately or during configuration.
    Ideally, this column should be empty.

    3. Focusing on a script, plugin, or lifecycle callback will show a break down of the tasks that were created.

[[sec:task_configuration_avoidance_pitfalls]]
=== Pitfalls

* [[task_configuration_avoidance_pitfalls_hidden_eager_task_realization]] **Beware of the hidden eager task realization.**
There are many ways that a task can be configured eagerly.  For example, configuring a task using the task name and a DSL block will cause the task to immediately be created when using the Groovy DSL:
+
[source,groovy]
----
// Given a task lazily created with
tasks.register("someTask")

// Some time later, the task is configured using a DSL block
someTask {
    // This causes the task to be created and this configuration to be executed immediately
}
----
+
Instead use the `named()` method to acquire a reference to the task and configure it:
+
[source,groovy]
----
tasks.named("someTask") {
    // ...
    // Beware of the pitfalls here
}
----
+
Similarly, Gradle has syntactic sugar that allows tasks to be referenced by name without an explicit query method.  This can also cause the task to be immediately created:
+
[source,groovy]
----
tasks.register("someTask")

// Sometime later, an eager task is configured like
task anEagerTask {
    // The following will cause "someTask" to be looked up and immediately created
    dependsOn someTask
}
----
+
There are several ways this premature creation can be avoided:

  - **Use a `TaskProvider` variable.**
  Useful when the task is referenced multiple times in the same build script.
+
====
[.multi-language-sample]
=====
[source,kotlin]
----
val someTask by tasks.registering

task("anEagerTask") {
    dependsOn(someTask)
}
----
=====
[.multi-language-sample]
=====
[source,groovy]
----
def someTask = tasks.register("someTask")

task anEagerTask {
    dependsOn someTask
}
----
=====
====

    - **Migrate the consumer task to the new API.**
+
[source,groovy]
----
tasks.register("someTask")

tasks.register("anEagerTask") {
    dependsOn someTask
}
----

    - **Lookup the task lazily.**
    Useful when the tasks are not created by the same plugin.
+
====
[.multi-language-sample]
=====
[source,kotlin]
----
tasks.register("someTask")

task("anEagerTask") {
    dependsOn(tasks.named("someTask"))
}
----
=====
[.multi-language-sample]
=====
[source,groovy]
----
tasks.register("someTask")

task anEagerTask {
    dependsOn tasks.named("someTask")
}
----
=====
====

* [[task_configuration_avoidance_pitfall_build_scan_plugin]] **The build scan plugin `buildScanPublishPrevious` task is eager until version 1.15.** Upgrade the build scan plugin in your build to use the latest version.

[[sec:task_configuration_avoidance_backward_compatibility_migration]]
==== Supporting older versions of Gradle

This section describes two ways to keep your plugin backward compatible with older version of Gradle if you must maintain compatibility with versions of Gradle older than 4.9. Most of the new API methods are available starting with Gradle 4.9.

NOTE: Although backward compatibility is good for users, we still recommended to upgrade to newer Gradle releases in a timely manner.
This will reduce your maintenance burden.

The first method to maintain compatibility is to compile your plugin against the Gradle 4.9 API and conditionally call the right APIs with Groovy (https://github.com/melix/jmh-gradle-plugin/blob/a034aa88805b7a06fa9c5a825d573554b2aa23e2/src/main/groovy/me/champeau/gradle/JMHPlugin.groovy#L289-L296[example]).

The second method is to use Java reflection to cope with the fact that the APIs are unavailable during compilation (https://github.com/tbroyer/gradle-apt-plugin/tree/432509ec85d1ab49296d4f9b21fad876523c6a8a/src/main/java/net/ltgt/gradle/apt[example]).

It is highly recommended to have cross-version test coverage using <<test_kit.adoc#sub:gradle-runner-gradle-version, TestKit>> and multiple versions of Gradle.

[[sec:old_vs_new_configuration_api_overview]]
== Old vs New API overview

* Methods that take a `groovy.lang.Closure` are covered in the new API with methods taking `org.gradle.api.Action`.
* More convenience methods may be added in the future based on user feedback.
* Some old API methods may never have a direct replacement in the new API.
* Some APIs may be restricted when accessed in a configuration action registered via the configuration avoidance methods.

[cols="a,a", options="header"]
|===
| Old API
| New API

| `task myTask(type: MyTask) {}`
| `tasks.register("myTask", MyTask) {}`
2+| There is not a shorthand Groovy DSL for using the new API.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.util.Map-[TaskContainer.create(java.util.Map)]
| No direct equivalent.
2+| Use one of the alternatives below.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.util.Map-groovy.lang.Closure-[TaskContainer.create(java.util.Map, groovy.lang.Closure)]
| No direct equivalent.
2+| Use one of the alternatives below.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.lang.String-[TaskContainer.create(java.lang.String)]
| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-[TaskContainer.register(java.lang.String)]
2+| This returns a `TaskProvider` instead of a `Task`.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.lang.String-groovy.lang.Closure-[TaskContainer.create(java.lang.String, groovy.lang.Closure)]
| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-org.gradle.api.Action-[TaskContainer.register(java.lang.String, org.gradle.api.Action)]
2+| This returns a `TaskProvider` instead of a `Task`.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.lang.String-java.lang.Class-[TaskContainer.create(java.lang.String, java.lang.Class)]
| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-java.lang.Class-[TaskContainer.register(java.lang.String, java.lang.Class)]
2+| This returns a `TaskProvider` instead of a `Task`.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.lang.String-java.lang.Class-org.gradle.api.Action-[TaskContainer.create(java.lang.String, java.lang.Class, org.gradle.api.Action)]
| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-java.lang.Class-org.gradle.api.Action-[TaskContainer.register(java.lang.String, java.lang.Class, org.gradle.api.Action)]
2+| This returns a `TaskProvider` instead of a `Task`.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.lang.String-java.lang.Class-java.lang.Object++...++-[TaskContainer.create(java.lang.String, java.lang.Class, java.lang.Object...)]
| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-java.lang.Class-java.lang.Object++...++-[TaskContainer.register(java.lang.String, java.lang.Class, java.lang.Object...)]
2+| This returns a `TaskProvider` instead of a `Task`.

| link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#getByName-java.lang.String-[TaskCollection.getByName(java.lang.String)]
| link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#named-java.lang.String-[TaskCollection.named(java.lang.String)]
2+| This returns a `TaskProvider` instead of a `Task`.

| link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#getByName-java.lang.String-groovy.lang.Closure-[TaskCollection.getByName(java.lang.String, groovy.lang.Closure)]
| `named(java.lang.String, Action)`
2+| This returns a `TaskProvider` instead of a `Task`.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#getByPath-java.lang.String-[TaskContainer.getByPath(java.lang.String)]
| No direct equivalent.
2+| Accessing tasks from another project requires a specific ordering of project evaluation.

| link:{javadocPath}/org/gradle/api/NamedDomainObjectCollection.html#findByName-java.lang.String-[NamedDomainObjectCollection.findByName(java.lang.String)]
| No direct equivalent.
2+| `named(String)` is the closest equivalent, but will fail if the task does not exist. Using `findByName(String)` will cause tasks registered with the new API to be created/configured.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#findByPath-java.lang.String-[TaskContainer.findByPath(java.lang.String)]
| No direct equivalent.
2+| See `getByPath(String)` above.

| link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#withType-java.lang.Class-[TaskCollection.withType(java.lang.Class)]
| _OK_
2+| This is OK to use because it does not require tasks to be created immediately.

| `withType(java.lang.Class).getByName(java.lang.String)`
| `named(java.lang.String, java.lang.Class)`
2+| This returns a `TaskProvider` instead of a `Task`.

| link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#withType-java.lang.Class-org.gradle.api.Action-[DomainObjectCollection.withType(java.lang.Class, org.gradle.api.Action)]
| `withType(java.lang.Class).configureEach(org.gradle.api.Action)`
2+| This returns `void`, so it cannot be chained.

| link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#all-org.gradle.api.Action-[DomainObjectCollection.all(org.gradle.api.Action)]
| link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#configureEach-org.gradle.api.Action-[DomainObjectCollection.configureEach(org.gradle.api.Action)]
2+| This returns `void`, so it cannot be chained.

| link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#whenTaskAdded-org.gradle.api.Action-[TaskCollection.whenTaskAdded(org.gradle.api.Action)]
| link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#configureEach-org.gradle.api.Action-[DomainObjectCollection.configureEach(org.gradle.api.Action)]
2+| This returns `void`, so it cannot be chained.

| link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#whenObjectAdded-org.gradle.api.Action-[DomainObjectCollection.whenObjectAdded(org.gradle.api.Action)]
| link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#configureEach-org.gradle.api.Action-[DomainObjectCollection.configureEach(org.gradle.api.Action)]
2+| This returns `void`, so it cannot be chained.

| link:{javadocPath}/org/gradle/api/NamedDomainObjectSet.html#findAll-groovy.lang.Closure-[NamedDomainObjectSet.findAll(groovy.lang.Closure)]
| _OK_, with issues.
2+| Avoid calling this method. `matching(Spec)` and `configureEach(Action)` are more appropriate in most cases.

| link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#matching-groovy.lang.Closure-[TaskCollection.matching(groovy.lang.Closure)]
| _OK_, with issues.
2+| If you are matching based on the name, use `named(Spec<String>)` instead which will be lazy.
    `matching(Spec)` requires all tasks to be created, so try to limit the impact by restricting the type of task, like `withType(java.lang.Class).matching(Spec)`.


| link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#getAt-java.lang.String-[TaskCollection.getAt(java.lang.String)]
| link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#named-java.lang.String-[TaskCollection.named(java.lang.String)]
2+| Avoid calling this directly as it's a Groovy convenience method. The alternative returns a `TaskProvider` instead of a `Task`.

| `iterator()` or implicit iteration over the `Task` collection
| _OK_, with issues.
2+| Avoid doing this as it requires creating and configuring all tasks. See `findAll(Closure)` above.

| `remove(org.gradle.api.Task)`
| _OK_, with issues.
2+| Avoid calling this. The behavior of `remove` with the new API may change in the future.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#replace-java.lang.String-[TaskContainer.replace(java.lang.String)]
| _OK_, with issues.
2+| Avoid calling this. The behavior of `replace` with the new API may change in the future.

| link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#replace-java.lang.String-java.lang.Class-[TaskContainer.replace(java.lang.String, java.lang.Class)]
| _OK_, with issues.
2+| Avoid calling this. The behavior of `replace` with the new API may change in the future.

|===
