anchor.diff:  .Configuration performance tab in build scan annotated
   image::taskConfigurationAvoidance-performance-annotated.png[]
   +
  -    1. Total tasks present when each task are created or not.
  -      - Created immediately represent all the task created using the eager task APIs.
  -      - Created during configuration represent all the tasks that were created using the lazy task APIs, but was realized explicitly (via `TaskProvider#get()`) or implicitly using the eager task query APIs.
  +    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 number represent all the task created while building the execution task graph.
  -      Typically, this number should be equal to the number of tasks that is executed.
  -      - Not created number represents all 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 scripts, plugins and lifecycle callbacks, the last column represents the tasks that were created either immediately or during configuration.
  +      - "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.
  -    The migration should be focusing on the build logic under your control.
  -
  -    3. Extending any scripts, plugins, or lifecycle callbacks subsection shows a break down in which project it was applied.
  -
  -* [[task_configuration_avoidance_troubleshooting_no_improvement]] **The build performance haven’t improved after migrating to lazy API.**
  -It is important to note that lazy task configuration is an opt-in feature.
  -It means the entire configuration chain needs to be lazy to get the benefit.
  -If at any point, an eager API is used for a specific named task, task type or, the worst, the entire task container, all benefits are mitigated.
  -The first step is to have a look at the statistics to see how much more the build can be improved.
  -If the statistic shows the build is completely lazy (work-avoided) https://github.com/gradle/gradle/issues/5664[please contact us] so we can discuss where this feature falls short and improve it for the next Gradle version.
  +
  +    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
   
  -* **Lazy task configuration is an opt-in feature.**
  -Any eager realization of a task will mitigate the benefit of this new API.
  -In the far future, eager realizations will become an error, until them, it’s up to the build author to avoid eager realization.
  -
   * [[task_configuration_avoidance_pitfalls_hidden_eager_task_realization]] **Beware of the hidden eager task realization.**
  -Gradle has lots of ways to configure a task eagerly.
  -`TaskContainer#getByName(String, Action)` is an explicit configuration by name.
  -Configuring a task as a DSL block is an alias to the previous explicit configuration, meaning a lazy task will be realized:
  +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:
   +
   [source,groovy]
   ----
   // Given a task lazily created with
   tasks.register("someTask")
   
  -// Some time later, the task is configured using a DSL block like
  +// Some time later, the task is configured using a DSL block
   someTask {
  -    // The task is realized immediately, and this closure is executed immediately
  -}
  -----
  -+
  -You will have to migrate the DSL task configuration to the following:
  +    // 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]
   ----
  
positive.code: 
  // Sometime later, an eager task is configured like
  task anEagerTask {
      // The task is realized immediately as it will be treated as a property of the project and will result in an eager task lookup by name
      dependsOn someTask
  }
  ----
  +
  You can solve this in three ways:
  
    - **Use `TaskProvider` variable.**
    Useful when the task is referenced multiple times in the same build script.
  +
  ====
  
negative.code: }
  ----
  +
  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]
  ----
  