anchor.diff:  
   Lastly, Gradle allows you to resolve dependencies against the <<declaring_repositories.adoc#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 <<declaring_repositories.adoc#sec:maven_repo,custom Maven repository>> with a file:// URL.
  +If you want to share published artifacts via the filesystem, consider configuring a <<declaring_repositories.adoc#sec:maven_repo,custom Maven repository>> with a `file://` URL.
   
   You might also be interested in learning about Gradle's own <<dependency_resolution.adoc#sec:dependency_cache,dependency cache>>, which behaves more reliably than Maven's and can be used safely by multiple concurrent Gradle processes.
   
  
positive.code: +
  This basically involves creating a root project build script that injects shared configuration into the appropriate subprojects.
  
  One notable feature that's missing is a standard way to share dependency versions across projects in a multi-project build.
  A common approach is to use <<writing_build_scripts#sec:extra_properties,extra properties>> in the root build script to store the versions, since those properties are visible from subprojects as well.
  
  [[migmvn:profiles_and_properties]]
  == Migrating Maven profiles and properties
  
negative.code: ====
  <1> Attaches version 1.2.12 of Log4J to the `implementation` configuration (scope)
  
  The string identifier takes the Maven values of `groupId`, `artifactId` and `version`, although Gradle refers to them as `group`, `module` and `version`.
  
  The above example raises an obvious question: what is that `implementation` configuration?
  It's one of the standard dependency configurations provided by the <<java_plugin#tab:configurations,Java Plugin>> and is often used as a substitute for Maven's default `compile` scope.
  