anchor.diff:  
   To approximate the time it takes to configure a build without executing tasks, you can run `gradle help`. Please use the Gradle Profiler to measure your build as described in <<sec:new_task_gradle_profiler_scenario>>.
   
  -[[sec:lazy_task_pitfalls]]
  +[[sec:task_configuration_avoidance_pitfalls]]
   ==== Pitfalls and examples
   
   The following guidelines should be followed when using the new APIs:
   
  -- Migrate task configuration that affects all tasks TODO (`tasks.all {}`) or subsets by type (`tasks.withType(...) {}`). This will cause your build to create fewer built-in Gradle task types.
  +- Migrate task configuration that affects all tasks (`tasks.all {}`) or subsets by type (`tasks.withType(...) {}`). This will cause your build to create fewer built-in Gradle task types.
   - Migrate tasks that are configured by name. 
  -- Migrate tasks created in custom plugins to use TODO `register(...)` and `configureEach {}`.
  +- Migrate tasks created in custom plugins to use `register(...)` and `configureEach {}`.
   - Use the information about which task types are created or use the old API to guide which build scripts or plugins to modify. 
  -- When inside a task configuration action, avoid configuring anything other than that task.  This includes other tasks and extensions. 
  +- When inside a task configuration action, avoid configuring anything other than that task. This includes other tasks, extensions or creating new tasks. 
   
   [[sec:old_vs_new_configuration_api_overview]]
   === Old vs New API overview
   
   [NOTE]
   ====
  -Methods that take a `groovy.lang.Closure` are covered in the new API with methods taking `org.gradle.api.Action`.
  +* 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.
   ====
   
   [cols="a,a", options="header"]
   |===
   | Old API | New API
   
  +| *Groovy DSL* `task myTask(type: MyTask) {}`
  +| `tasks.register("myTask", MyTask) {}`
  +2+| There is not a shorthand DSL for using the new API.
  +
   | api:org.gradle.api.tasks.TaskContainer#create(java.util.Map)[]
   | No direct equivalent.
   2+| Use one of the alternatives below.
  
positive.code: - Try your build with the latest nightly (see the version number at the top of this page).
  - How many tasks do you see registered with the new API?  See <<sec:how_do_i_know_its_working>> for how to find this.
  - Which task types do you have a lot of? Which ones are created with the old API? Which ones are registered with the new API, but have been created/configured anyways?
  - Following <<sec:lazy_task_pitfalls>>, change your build scripts to use the new API to avoid creating/configuring tasks that are from the built-in Gradle plugins. Is there an impact to the number of lazy tasks that are created?
  - Convert some of your custom plugins/tasks to use the new API.  Is there an impact to the number of tasks using the new API and the number of new API tasks that are created?
  - Run the https://github.com/gradle/gradle-profiler[gradle-profiler] to measure the difference between a lazy build and a completely eager build. What do you see? Use <<sec:new_task_gradle_profiler_scenario,the scenario file below>>.
  
  [[sec:lazy_task_guidelines]]
  === Guidelines
  
  [[sec:how_do_i_defer_creation]]
  
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?
  