anchor.diff:  * 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.
  +
  +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[].
  +
  +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.
   
  
positive.code:         </sample>
  ++++
  
  In the example above, <code>orca</code> has a dependency on <code>seal-1.0</code> whereas <code>shark</code> has a dependency on<code>seal-2.0</code>. The original configuration has therefore a version conflict which is resolved to the newer <code>seal-2.0</code> version. The <code>files</code> method therefore returns <code>seal-2.0</code> as a transitive dependency of<code>orca</code>. The copied configuration only has <code>orca</code> as a dependency and therefore there is no version conflict and <code>seal-1.0</code> is returned as a transitive dependency.
  
  Once a configuration is resolved it is immutable. Changing its state or the state of one of its dependencies will cause an exception. You can always copy a resolved configuration. The copied configuration is in the unresolved state and can be freshly resolved.
  
  
negative.code: 
  [NOTE]
  ====
  _NOTE:_ In one project, we found a mystery LDAP related jar in the classpath. No code referenced this jar and there was no connection to the project. No one could figure out what the jar was for, until it was removed from the build and the application suffered massive performance problems whenever it attempted to authenticate to LDAP. This mystery jar was a necessary transitive, fourth-level dependency that was easy to miss because no one had bothered to use managed transitive dependencies.
  ====
  
  Gradle offers you different ways to express first-level and transitive dependencies. With Gradle you can mix and match approaches; for example, you could store your jars in an SCM without XML descriptor files and still use transitive dependency management.
  