anchor.diff:  
   You can also use the `repositories {}` block to configure custom repositories, as described in the <<repository_types#sub:maven_repo,Repository Types>> chapter.
   
  +Lastly, Gradle allows you to resolve dependencies against the <<repository_types#sub:maven_local,local Maven cache/repository>>.
  +This helps Gradle builds interoperate with Maven builds, but it shouldn't be a technique that you use if you don't need that interoperability.
  +If you want to share published artifacts via the filesystem, consider configuring a <<repository_types#sub:maven_repo,custom Maven repository>> with a file:// URL.
  +
  +You might also be interested in learning about Gradle's own <<dependency_cache#dependency_cache,dependency cache>>, which behaves more reliably than Maven's and can be used safely by multiple concurrent Gradle processes.
  +
  +
   [[migmvn:excluding_deps]]
   === Excluding transitive dependencies
   
   Maven builds use exclusions to keep unwanted dependencies -- or unwanted _versions_ of dependencies -- out of the dependency graph.
  -These can be tricky to migrate not because Gradle doesn't have good support for such exclusions, but because you really need to understand _why_ an exclusion is in place to migrate it properly.
  +You can do the same thing with Gradle, but that's not necessarily the _right_ thing to do.
  +Gradle provides other options that may be more appropriate for a given situation, so you really need to understand _why_ an exclusion is in place to migrate it properly.
   
   If you want to exclude a dependency for reasons unrelated to versions, then check out the section on <<managing_transitive_dependencies#sec:excluding_transitive_module_dependencies,Excluding transitive module dependencies>>.
   It shows you how to attach an exclusion either to an entire configuration (often the most appropriate solution) or to a dependency.
   You can even easily apply an exclusion to all configurations.
   
   If you're more interested in controlling which version of a dependency is actually resolved, then Gradle has better options than exclusions.
  -Consider using <<managing_transitive_dependencies#sec:dependency_constraints,dependency constraints>> or <<managing_transitive_dependencies#sec:enforcing_dependency_version,forcing a particular version>>.
  +Consider <<managing_transitive_dependencies#sec:dependency_constraints,using dependency constraints>> or <<managing_transitive_dependencies#sec:enforcing_dependency_version,forcing a particular version>>.
   
   [[migmvn:optional_deps]]
   === Handling optional dependencies
  
positive.code:  * How the build treats them as transitive dependencies
   * How declared dependencies are published as optional
  
  For the first scenario, Gradle simply ignores any transitive dependencies that are declared as optional.
  They are not resolved and have no impact on the versions selected if the same dependencies appear elsewhere in the dependency graph as non-optional.
  
  As for publishing dependencies as optional, Gradle has no built-in support at this time.
  However, you can use the https://plugins.gradle.org/plugin/nebula.optional-base[Nebula Optional Base Plugin] to get the required behavior.
  
  [[migmvn:using_boms]]
  == Using bills of materials (BOMs)
  
negative.code: === Declaring repositories
  
  Gradle allows you to retrieve declared dependencies from any Maven-compatible or Ivy-compatible repository.
  Unlike Maven, it has no default repository and so you have to declare at least one.
  In order to have the same behavior as your Maven build, just configure <<repository_types#sub:maven_central,Maven Central>> in your Gradle build, like this:
  
  .Configuring the build to use Maven Central
  