anchor.diff:  The latter allows to quickly see which tasks are problematic.
   In both cases you can expand the tree in order to discover where in the object graph is the culprit.
   
  -Problems displayed in the report have links to the corresponding <<configuration_cache#constraints,constraint>> where you can find guidance on how to fix the problem or to the corresponding <<configuration_cache#not_yet_implemented,not yet implemented>> feature.
  +Problems displayed in the report have links to the corresponding <<configuration_cache#requirements,requirement>> where you can find guidance on how to fix the problem or to the corresponding <<configuration_cache#not_yet_implemented,not yet implemented>> feature.
  
positive.code: A task must not use any `Project` objects at execution time.
  This includes calling `Task.getProject()` while the task is running.
  
  Some cases can be fixed in the same way as the previous constraint.
  
  Otherwise, to fix, use <<custom_gradle_types#service_injection,injected services>> instead of the methods of `Project`:
  
  
negative.code: ----
  
  
  [[requirements]]
  == Requirements
  
  In order to capture the state of the task graph to the configuration cache and reload it again in a later build, Gradle applies certain requirements to tasks and other build logic.
  Each of these requirements is treated as a configuration cache "problem" and fail the build if violations are present.
  
  The following sections describe each of the requirements and how to change your build to fix the problems.
  
  [[disallowed_types]]
  === Certain types must not be referenced by tasks
  