anchor.diff:   * The Maven Wagon libraries used to access Maven repositories have been upgraded from 2.4 to 3.0.0.
    * SLF4J has been upgraded from 1.7.16 to https://www.slf4j.org/news.html[1.7.25].
   
  -[[rel5.0:dependency_resolution]]
  -=== [5.0] Fixes to dependency resolution
  -
  -Various issues have been fixed in Gradle's dependency resolution for this release. By definition this could impact the set of resolved dependencies of your build.
  +[[rel5.0:dependency_constraints]]
  +=== [5.0] Improved support for dependency and version constraints
  +
  +Through the Gradle 4.x release stream, new `@Incubating` features were added to the dependency resolution engine.
  +These include sophisticated version constraints (`prefer`, `strictly`, `reject`), dependency constraints, and `platform` dependencies.
  +
   If you have been using the `IMPROVED_POM_SUPPORT` feature preview, playing with constraints or prefer, reject and other specific version indications, then make sure to take a good look at your dependency resolution results.
  +
  +[[rel5.0:bom_import]]
  +=== [5.0] BOM import
  +
  +Gradle now provides support for importing bill of materials (BOM) files, which are effectively POM files that use `<dependencyManagement>` sections to control the versions of direct and transitive dependencies. All you need to do is declare the POM as a `platform` dependency.
  +
  +The following example picks the versions of the `gson` and `dom4j` dependencies from the declared Spring Boot BOM:
  +
  +----
  +dependencies {
  +    // import a BOM
  +    implementation platform('org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE')
  +
  +    // define dependencies without versions
  +    implementation 'com.google.code.gson:gson'
  +    implementation 'dom4j:dom4j'
  +}
  +----
  +
  +[[rel5.0:pom_compile_runtime_separation]]
  +=== [5.0] Separation of compile and runtime dependencies when consuming POMs
  +
  +Since Gradle 1.0, runtime-scoped dependencies have been included in the Java compilation classpath, which has some drawbacks:
  +
  + * The compilation classpath is much larger than it needs to be, slowing down compilation.
  + * The compilation classpath includes runtime-scoped files that do not impact compilation, resulting in unnecessary re-compilation when those files change.
  +
  +With this new behavior, the Java and Java Library plugins both honor the <<java_library_plugin.adoc#sec:java_library_separation,separation of compile and runtime scopes>>. This means that the compilation classpath only includes compile-scoped dependencies, while the runtime classpath adds the runtime-scoped dependencies as well. This is particularly useful if you develop and publish Java libraries with Gradle where the separation between `api` and `implementation` dependencies is reflected in the published scopes.
   
   [[rel5.0:changes_to_default_task]]
   === [5.0] Changes to property factory methods on `DefaultTask`
  
positive.code: 
  The following breaking changes are not from deprecations, but the result of changes in behavior:
  
   * Optional dependency declarations in POMs no longer influence the version of a dependency that Gradle picks.
  +
  This change is only applicable if you had the `IMPROVED_POM_SUPPORT` preview feature enabled.
   * The evaluation of the `publishing {}` block is no longer deferred until needed but behaves like any other block.
     Please use `afterEvaluate {}` if you need to defer evaluation.
   * The link:{groovyDslPath}/org.gradle.api.tasks.javadoc.Javadoc.html[`Javadoc`] and link:{groovyDslPath}/org.gradle.api.tasks.javadoc.Groovydoc.html[`Groovydoc`] tasks now delete the destination dir for the documentation before executing. This has been added to remove stale output files from the last task execution.
  
negative.code:  * The IdeaModule Tooling API model element contains methods to retrieve resources and test resources so those elements were removed from the result of `IdeaModule.getSourceDirs()` and `IdeaModule.getTestSourceDirs()`.
   * In previous Gradle versions, the `source` field in `SourceTask` was accessible from subclasses. This is not the case anymore as the `source` field is now declared as `private`.
   * In the Worker API, <<#rel5.0_worker_api, the working directory of a worker can no longer be set>>.
   * A change in behavior related to <<#rel5.0:dependency_constraints,dependency and version constraints>> may impact a small number of users.
   * There have been several changes to <<#rel5.0:changes_to_default_task,property factory methods on DefaultTask>> that may impact the creation of custom tasks.
  
  [[changes_4.10]]
  