anchor.diff:  Now we see that, instead of executing the `:compileJava` task, the outputs of the task have been loaded from the build cache.
   The other tasks have not been loaded from the build cache since they are not cacheable. This is due to
   `:classes` and `:assemble` being <<sec:lifecycle_tasks,lifecycle tasks>> and `:processResources`
  -and `jar` being Copy-like tasks which are not cacheable since it is generally faster to execute them.
  +and `:jar` being Copy-like tasks which are not cacheable since it is generally faster to execute them.
   
   [[sec:task_output_caching_details]]
  -==== Task Output Caching in Detail
  +==== Task Output Caching in detail
   
   Since a task describes all of its inputs and outputs, Gradle can compute a _build cache key_ that uniquely defines the task's outputs based on its inputs.
   That build cache key is used to request previous outputs from a build cache or push new outputs to the build cache. If the previous build is already populated by someone else, e.g. your
  
positive.code: 
  
  [[sec:build_cache_known_issues]]
  === Known Issues with built-in Build Caches
  
  The built-in build caches have some known issues which will be addressed in future releases.
  
  
negative.code: Beyond incremental builds described in <<sec:up_to_date_checks>>, Gradle can save time by reusing outputs from previous executions of a task by matching inputs to the task.
  Task outputs can be reused between builds on one computer or even between builds running on different computers via a build cache.
  
  For an initial release, we have focused on the use case where users have an organization-wide remote build cache that is populated regularly by continuous integration builds.
  Developers and other continuous integration agents should pull cache entries from the remote build cache.
  We expect that developers will not be allowed to populate the remote build cache, and all continuous integration builds populate the build cache after running the `clean` task.
  
  