anchor.diff:  
   * Given a required dependency, Gradle first attempts to resolve the _module_ for that dependency. Each repository is inspected in order, searching first for a _module descriptor_ file (POM or Ivy file) that indicates the presence of that module. If no module descriptor is found, Gradle will search for the presence of the primary _module artifact_ file indicating that the module exists in the repository.
   
  -* If the dependency is declared as a dynamic version (like `1.+`), Gradle will resolve this to the newest available static 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 descriptor is a POM file that has a parent POM declared, Gradle will recursively attempt to resolve each of the parent modules for the POM.
  +** If the dependency is declared as a dynamic version (like `1.+`), Gradle will resolve this to the newest available static 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 descriptor 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' static version is preferred over a 'lower' version.
  -* Modules declared by a module descriptor file (Ivy or POM 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 static version and a module descriptor file is found in a repository, there is no need to continue searching later repositories and the remainder of the process is short-circuited.
  +** For a dynamic version, a 'higher' static version is preferred over a 'lower' version.
  +
  +** Modules declared by a module descriptor file (Ivy or POM 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 static version and a module descriptor 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.
   
   
  
positive.code: * Avoid dependencies that pull in legacy libraries.
  * Upgrade the dependency version if the new version no longer pulls in a legacy library.
  * Downgrade to "google-collections". It's not recommended, just mentioned for completeness.
   Traditional approaches work but they are not general enough. For example, an organisation wants to resolve the google-collections VS guava conflict resolution problem in all projects. Starting from Gradle 2.2 it is possible to declare that certain module was replaced by other. This enables organisations to include the information about module replacement in the corporate plugin suite and resolve the problem holistically for all Gradle-powered projects in the enterprise.
  ++++
  <sample id="module_replacement_declaration" dir="userguide/artifacts/componentModuleMetadata" title="Declaring module replacement">
                      <sourcefile file="build.gradle" snippet="module_replacement_declaration"/>
                  </sample>
  ++++
   For more examples and detailed API, please refer to the DSL reference for api:org.gradle.api.artifacts.dsl.ComponentMetadataHandler[].
  
  What happens when we declare that "google-collections" are replaced by "guava"? Gradle can use this information for conflict resolution. Gradle will consider every version of "guava" newer/better than any version of "google-collections". Also, Gradle will ensure that only guava jar is present in the classpath / resolved file list. Please note that if only "google-collections" appears in the dependency graph (e.g. no "guava") Gradle will not eagerly replace it with "guava". Module replacement is an information that Gradle uses for resolving conflicts. If there is no conflict (e.g. only "google-collections" or only "guava" in the graph) the replacement information is not used.
  
  
negative.code:             </sample>
  ++++
  
  You can also assign collections or arrays of dependency notations to a configuration:
  
  ++++
  