anchor.diff:  They only declare relationships.
   ====
   
  -link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:mustRunAfter(java.lang.Object++[]++)[Task.mustRunAfter(...)] and link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:shouldRunAfter(java.lang.Object++[]++)[Task.shouldRunAfter(...)] represent soft relationships.
  -These relationships will _order_ execution between the related tasks, but only if they exist in the same execution.
  -They will not, in any context, cause task creation.
  -
  -link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:dependsOn(java.lang.Object++[]++)[Task.dependsOn(...)] and link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:finalizedBy(java.lang.Object++[]++)[Task.finalizedBy(...)] represent strong relationships.
  -These relationships will _force_ a task to be at least configured, but the same applies as before: calling these methods will not result in task creation.
  -What's important is to understand in which context they will cause an effect:
  -
  -- If a task is _not_ executed (regardless if it was created with link:{groovyDslPath}/org.gradle.api.tasks.TaskContainer.html#org.gradle.api.tasks.TaskContainer:register(java.lang.String)[Task.register(...)]
  -or link:{groovyDslPath}/org.gradle.api.tasks.TaskContainer.html#org.gradle.api.tasks.TaskContainer:create(java.lang.String)[Task.create(...)]), the defined relationships will not trigger any task creation.
  -- If a task _is_ executed, all strongly associated tasks need to be created and configured, as they might have other `dependsOn` or `finalizedBy` relationships.
  -This will happen transitively, until there is a task without strong relationships.
  +link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:mustRunAfter(java.lang.Object++[]++)[Task.mustRunAfter(...)] and link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:shouldRunAfter(java.lang.Object++[]++)[Task.shouldRunAfter(...)] represent soft relationships. These relationships will _order_ execution between the related tasks, but only if they exist in the same execution. They will not, in any context, cause task creation.
  +
  +link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:dependsOn(java.lang.Object++[]++)[Task.dependsOn(...)] and link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:finalizedBy(java.lang.Object++[]++)[Task.finalizedBy(...)] represent strong relationships. These relationships will _force_ a task to be at least configured, but the same applies as before: calling these methods will not result in task creation. What's important is to understand in which context they will cause an effect:
  +
  +- If a task is _not_ executed (regardless if it was created with link:{groovyDslPath}/org.gradle.api.tasks.TaskContainer.html#org.gradle.api.tasks.TaskContainer:register(java.lang.String)[Task.register(...)] or link:{groovyDslPath}/org.gradle.api.tasks.TaskContainer.html#org.gradle.api.tasks.TaskContainer:create(java.lang.String)[Task.create(...)]), the defined relationships will not trigger any task creation.
  +- If a task _is_ executed, all strongly associated tasks need to be created and configured, as they might have other `dependsOn` or `finalizedBy` relationships. This will happen transitively, until there is a task without strong relationships.
   
   [[sec:task_configuration_avoidance_migration_guidelines]]
   == Migration Guide
  
positive.code: 3. **Migrate tasks creation to `register(...)`.**
  At this point, you should change anywhere that you are creating tasks to instead register those tasks.
  
  For all steps above, be aware of the <<#sec:task_configuration_avoidance_pitfalls, common pitfalls around deferred configuration>>.
  
  After making these changes, you should see improvement in the number of tasks that are eagerly created at configuration time.
  Use <<#sec:task_configuration_avoidance_troubleshooting, build scans>> to understand what tasks are still being created eagerly and where this is happening.
  
  [[sec:task_configuration_avoidance_troubleshooting]]
  === Troubleshooting
  
  * **What tasks are being realized?**
  As we keep developing the feature, more reporting, and troubleshooting information will be made available to answer this question.
  In the meantime, https://gradle.com/enterprise/releases/2018.3#reduce-configuration-time-by-leveraging-task-creation-avoidance[build scan is the best way to answer this question].
  Follow these steps:
  
  a. https://scans.gradle.com/[Create a build scan].
  Execute the Gradle command using the `--scan` flag.
  
  b. Navigate to the configuration performance tab.
  +
  .Navigate to configuration performance tab in build scan
  image::taskConfigurationAvoidance-navigate-to-performance.png[]
  +
  1. Navigate to the performance card from the left side menu.
  2. Navigate to the configuration tab from the top of the performance card.
  
  c. All the information requires will be presented.
  +
  .Configuration performance tab in build scan annotated
  image::taskConfigurationAvoidance-performance-annotated.png[]
  +
  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" 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.
  
  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
  
  * [[task_configuration_avoidance_pitfalls_hidden_eager_task_realization]] **Beware of the hidden eager task realization.**
  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]
  ----
  
negative.code: 
  Effective task configuration avoidance requires build authors to change instances of link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#create-java.lang.String-[TaskContainer.create(java.lang.String)] to link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-[TaskContainer.register(java.lang.String)].
  
  Older versions of Gradle only support the `create(...)` API. The `create(...)` API eagerly creates and configures tasks when it is called and should be avoided.
  
  Using `register(...)` alone may not be enough to avoid all task configuration completely. You may need to change other code that configures tasks by name or by type, as explained in the following sections.
  
  [[sec:how_do_i_defer_configuration]]
  === How do I defer task configuration?
  
  Eager APIs like link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#all-org.gradle.api.Action-[DomainObjectCollection.all(org.gradle.api.Action)] and link:{javadocPath}/org/gradle/api/DomainObjectCollection.html#withType-java.lang.Class-org.gradle.api.Action-[DomainObjectCollection.withType(java.lang.Class, org.gradle.api.Action)] will immediately create and configure any registered tasks. To defer task configuration, you will need to migrate to a configuration avoidance API equivalent. See the <<#sec:old_vs_new_configuration_api_overview,table below>> to identify the alternative.
  
  [[sec:how_do_i_reference_a_task]]
  === How do I reference a task without creating/configuring it?
  
  Instead of referencing a task object, you can work with a registered task via a link:{javadocPath}/org/gradle/api/tasks/TaskProvider.html[TaskProvider] object.  A link:{javadocPath}/org/gradle/api/tasks/TaskProvider.html[TaskProvider] can be obtained in several ways including when calling link:{javadocPath}/org/gradle/api/tasks/TaskContainer.html#register-java.lang.String-[TaskContainer.register(java.lang.String)] or using the link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#named-java.lang.String-[TaskCollection.named(java.lang.String)] method.
  
  Calling link:{javadocPath}/org/gradle/api/provider/Provider.html#get--[Provider.get()] or looking up a task by name with link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#getByName-java.lang.String-[TaskCollection.getByName(java.lang.String)] will cause the task to be created and configured. Methods like link:{groovyDslPath}/org.gradle.api.Task.html#org.gradle.api.Task:dependsOn(java.lang.Object++[]++)[Task.dependsOn(java.lang.Object...)] and link:{javadocPath}/org/gradle/api/file/ConfigurableFileCollection.html#builtBy-java.lang.Object++...++-[ConfigurableFileCollection.builtBy(java.lang.Object++...++)] work with link:{javadocPath}/org/gradle/api/tasks/TaskProvider.html[TaskProvider] in the same way as link:{groovyDslPath}/org.gradle.api.Task.html[Task], so you do not need to unwrap a `Provider` for explicit dependencies to continue to work.
  
  If you are configuring a task by name, you will need to use the configuration avoidance equivalent. See the <<#sec:old_vs_new_configuration_api_overview,table below>> to identify the alternative.
  
  [[sec:how_do_i_get_a_task]]
  === How to get an instance of a Task?
  
  In the event you still need to get access to a Task instance, you can use link:{javadocPath}/org/gradle/api/tasks/TaskCollection.html#named-java.lang.String-[TaskCollection.named(java.lang.String)] and call link:{javadocPath}/org/gradle/api/provider/Provider.html#get--[Provider.get()].  This will cause the task to be created/configured, but everything should work as it has with the eager APIs.
  
  [[sec:how_do_i_order_tasks]]
  === How do I order tasks?
  