anchor.diff:  === Cache Locking
   
   The Gradle dependency cache uses file-based locking to ensure that it can safely be used by multiple Gradle processes concurrently.
  -The lock is held whenever the binary meta-data store is being read or written, but is released for slow operations such as downloading remote artifacts.
  +The lock is held whenever the binary metadata store is being read or written, but is released for slow operations such as downloading remote artifacts.
  +
  +This concurrent access is only supported if the different Gradle processes can communicate together. This is usually _not the case_ for containerized builds.
   
   [[sub:cache_cleanup]]
   ==== Cache Cleanup
  
positive.code: This chapter covers the way dependency resolution works _inside_ Gradle.
  After covering how you can declare <<declaring_repositories.adoc#,repositories>> and <<declaring_dependencies.adoc#,dependencies>>, it makes sense to explain how these declarations come together during dependency resolution.
  
  [[sec:how-gradle-downloads-deps]]
  == How Gradle downloads dependencies
  
  Gradle takes your dependency declarations and repository definitions and attempts to download all of your dependencies by a process called _dependency resolution_. Below is a brief outline of how this process works.
  
  * Given a required dependency, Gradle attempts to resolve the dependency by searching for the module the dependency points at. Each repository is inspected in order. Depending on the type of repository, Gradle looks for metadata files describing the module (`.module`, `.pom` or `ivy.xml` file) or directly for artifact files.
  
  ** If the dependency is declared as a dynamic version (like `1.+`, `[1.0,)`, `[1.0, 2.0)`), Gradle will resolve this to the highest available concrete version (like `1.2`) in the repository. For Maven repositories, this is done using the `maven-metadata.xml` file, while for Ivy repositories this is done by directory listing.
  
  ** If the module metadata is a POM file that has a parent POM declared, Gradle will recursively attempt to resolve each of the parent modules for the POM.
  
  * Once each repository has been inspected for the module, Gradle will choose the 'best' one to use. This is done using the following criteria:
  
  ** For a dynamic version, a 'higher' concrete version is preferred over a 'lower' version.
  
  ** Modules declared by a module metadata file (`.module`, `.pom` or `ivy.xml` file) are preferred over modules that have an artifact file only.
  
  ** Modules from earlier repositories are preferred over modules in later repositories.
  
  ** When the dependency is declared by a concrete version and a module metadata file is found in a repository, there is no need to continue searching later repositories and the remainder of the process is short-circuited.
  
  * All of the artifacts for the module are then requested from the _same repository_ that was chosen in the process above.
  
  The dependency resolution process is highly customizable to meet enterprise requirements. For more information, see the chapter on <<customizing_dependency_resolution_behavior.adoc#customizing_dependency_resolution_behavior,customizing dependency resolution>>.
  
  [[sub:http-retries]]
  === HTTP Retries
  
  Gradle will make several attempts to connect to a given repository. If it fails, Gradle will retry, increasing the amount of time waiting between each retry. After a max number of failed attempts, the repository will be blacklisted for the whole build.
  
  [[sec:dependency_cache]]
  == The Dependency Cache
  
negative.code: 
  The Gradle dependency cache consists of two storage types located under `GRADLE_USER_HOME/caches`:
  
  * A file-based store of downloaded artifacts, including binaries like jars as well as raw downloaded meta-data like POM files and Ivy files.
  The storage path for a downloaded artifact includes the SHA1 checksum, meaning that 2 artifacts with the same name but different content can easily be cached.
  * A binary store of resolved module metadata, including the results of resolving dynamic versions, module descriptors, and artifacts.
  
  The Gradle cache does not allow the local cache to hide problems and create other mysterious and difficult to debug behavior.
  Gradle enables reliable and reproducible enterprise builds with a focus on bandwidth and storage efficiency.
  