anchor.diff:  ----
   
       - **Migrate consumer task.**
  -    It will only work under specific circumstance.
  -    If the task gets resolve later or the realization may happen in a configuration action with no ways of actually knowing where the task is created or configured
  -
  +    It will only work under specific circumstances.
  +    If the task gets resolve later or the realization may happen in a configuration action with no ways of actually knowing where the task is created or configured, this solution won't be helpful.
  ++
   [source,groovy]
   ----
   tasks.register "someTask"
  
positive.code: [[sec:task_configuration_avoidance_migration_guidelines]]
  === Migration Guide
  
  [[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 completely lazy build, https://scans.gradle.com/s/o7qmlmmrsfxz4/performance/configuration?openScriptsAndPlugins=WzFd[a build scan should show no task created immediately or created during configuration].
  Only a single task, the `help` task, should be created during task graph calculation.
  Be mindful of the pitfall around the lazy API usage of the build scan plugin.
  
  2. [[task_configuration_avoidance_guideline_only_mutate_task_object]] **Only mutate the current task during configuration action.**
  Because the task configuration action can now run immediately, later or never, mutating anything other than the current task will expose flaky-like behavior in your build.
  In the future, Gradle will consider these flaky-mutation a failure.
  It also means the configuration needs to flow from the extensions to the tasks.
  Thus, the task should by configured by the extension and not the other way around.
  
  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 change log since the last successful verification.
  
  4. [[task_configuration_avoidance_guideline_validate_build_logic]] **Ensure a good plan is establish for validating the build logic.**
  Usually, a simple `build` task invocation should do the trick to validate all corner of your build logic.
  However, if all automation aspect is centralize around Gradle, you may need to validate other task execution path.
  
  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 the case, referencing a task by name is a fragile pattern and should be avoided.
  Although task name is available on the `TaskProvider`, effort should be made to use reference strongly typed model instead.
  
  7. **Use the lazy task API as much as possible.**
  Although realizing a task within a lazy configuration action may not have any immediate impact, it make misuse of the lazy API more costly.
  The lazy task API is an opt-in feature, meaning someone may be realizing task eagerly which would cause the realization to transitively realize other tasks.
  Using `TaskProvider` helps create an indirection that protect transitive realization.
  
  [[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 lazy APIs.
  The following explore the recommended steps for a successful migration.
  While going through those steps, keep in mind <<task_configuration_avoidance_general, the guidelines>>.
  
  1. **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.
  Note that despite some built-in Gradle task aren’t using the lazy APIs, the configuration affecting those task type should still be migrated.
  We recommend using regex code search capability offered by modern IDE.
  For example, the regex `\.all\s*((\(?\s*\{)|\(\s*new)` will identify every call to `.all` of a `DomainObjectCollection` and subtype.
  We will need to go through those result and identify and migrate only the method calls affecting the `TaskContainer` or `TaskCollection`.
  Be aware of the <<sec:task_configuration_avoidance_pitfalls, common pitfall around deferred configuration>>.
  
  
negative.code: ----
  
      - **Lookup the task lazily.**
      Useful when the task registration isn’t co-located with its eager usage.
  +
  [source,groovy]
  ----
  tasks.register "someTask"
  