anchor.diff:  
   // 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
  +    // The following will cause "someTask" to be looked up and immediately created
       dependsOn someTask
   }
   ----
   +
  -You can solve this in three ways:
  -
  -  - **Use `TaskProvider` variable.**
  +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.
   +
   ====
  
positive.code: .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.
        - 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.
      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.
  
  [[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:
  +
  [source,groovy]
  ----
  // Given a task lazily created with
  tasks.register("someTask")
  
  // Some time later, the task is configured using a DSL block like
  someTask {
      // The task is realized immediately, and this closure is executed immediately
  }
  ----
  +
  You will have to migrate the DSL task configuration to the following:
  +
  [source,groovy]
  ----
  
negative.code: [[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]
  ====
  