anchor.diff:  [[sec:what_is_new_task_configuration]]
   === What is the new API good for?
   
  -In a nutshell, the new API allows builds to avoid the cost of creating and configuring tasks during Gradle's configuration phase. Instead of immediately creating a task and running all configuration actions, Gradle exposes a api:org.gradle.api.provider.Provider[] to a task. We call these "lazy tasks". A task will only be created and configured when the task is required (usually execution). We identified task configuration as a contributor to overall configuration time, especially in large multi-project builds.
  -
  -This feature is designed to be backwards compatible when mixed with the old and new APIs, so you can gradually migrate your plugins and build scripts to the new API. If at any point, a task registered with the new API is accessed through the old API, the task will be created and configured just as if it had been created with the old API.
  +In a nutshell, the new API allows builds to avoid the cost of creating and configuring tasks during Gradle's configuration phase when those tasks will never be executed. We identified task configuration as a contributor to overall configuration time. Configuration time affects every build, so making it faster is good for everyone. For example, if you're only compiling, Gradle doesn't need to also configure code quality, testing and publishing tasks. For tasks that aren't used often by developers, configuration can be expensive (e.g., running `git status` or querying a webservice) and can slow down builds that do not need to execute them. This new API avoids configuring those tasks if they are not needed.
  +
  +This feature is designed to be backwards compatible when mixed with the old and new APIs, so you can gradually migrate your plugins and build scripts to the new API. Instead of immediately creating a task and running all configuration actions, Gradle exposes a api:org.gradle.api.provider.Provider[] to a task. A task will only be created and configured when the task is required. If at any point, a task registered with the new API is accessed through the old API, the task will be created and configured just as if it had been created with the old API.
   
   Many built-in Gradle plugins have been converted to use this new API already, so you may see some benefits without changing anything.
   
  
positive.code: | api:org.gradle.api.tasks.TaskCollection#getAt(java.lang.String)[]
  | api:org.gradle.api.tasks.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`.
  
  | `remove(org.gradle.api.Task)`
  | _OK_, with issues.
  
negative.code: 
  In the event you still need to get access to a Task instance, you can use api:org.gradle.api.tasks.TaskCollection#named(java.lang.String)[] and call api:org.gradle.api.provider.Provider#get()[].  This will cause the task to be created/configured, but everything should work as it has with the eager APIs. 
  
  Please https://github.com/gradle/gradle/issues/5664[contact us] if you find tricky build logic that requires you to get a Task instance. 
  
  [[sec:how_do_i_know_its_working]]
  ==== How do I know if it's working?
  