anchor.diff:  == Handling mutually exclusive dependencies
   
   [[sec:capabilities]]
  -=== Component capabilities
  -
  -==== Introduction to capabilities
  +=== Introduction to component capabilities
   
   Often a dependency graph would accidentally contain multiple implementations of the same API.
   This is particularly common with logging frameworks, where multiple bindings are available, and that one library chooses a binding when another transitive dependency chooses another.
  
positive.code: Dependency substitution rules take care of replacing the module dependency with the project dependency and wiring up any task dependencies, but do not implicitly include the project in the build.
  
  [[sec:project_to_module_substitution]]
  ===== Substituting a project dependency with a module replacement
  
  Another way to use substitution rules is to replace a project dependency with a module in a multi-project build.
  This can be useful to speed up development with a large multi-project build, by allowing a subset of the project dependencies to be downloaded from a repository rather than being built.
  
negative.code: With this functionality, Gradle can no longer make this assumption, and must perform a full resolve in order to determine the project dependencies.
  
  [[sec:module_to_project_substitution]]
  ==== Substituting an external module dependency with a project dependency
  
  One use case for dependency substitution is to use a locally developed version of a module in place of one that is downloaded from an external repository.
  This could be useful for testing a local, patched version of a dependency.
  