anchor.diff:  
   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.
  + * <<#rel5.0:pom_compile_runtime_separation,Separation of compile and runtime dependencies when consuming POMs>>
    * 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.
  
positive.code:  * link:{javadocPath}/org/gradle/language/swift/tasks/SwiftCompile.html[SwiftCompile]
   * link:{javadocPath}/org/gradle/nativeplatform/tasks/LinkMachOBundle.html[LinkMachOBundle]
  
  [[rel4.6:bom_import]]
  === [4.6] 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 just another dependency.
  
  The following example picks the versions of the `gson` and `dom4j` dependencies from the declared Spring Boot BOM:
  
  ----
  dependencies {
      // import a BOM
      implementation 'org.springframework.boot:spring-boot-dependencies:1.5.8.RELEASE'
  
      // define dependencies without versions
      implementation 'com.google.code.gson:gson'
      implementation 'dom4j:dom4j'
  }
  ----
  
  [[rel4.6:pom_compile_runtime_separation]]
  === [4.6] 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.
  
  [[rel4.6:visual_studio_single_solution]]
  === [4.6] Visual Studio integration only supports a single solution file for all components of a build
  
  
negative.code: [[changes_4.6]]
  == Upgrading from 4.5 and earlier
  
  === Deprecations
  
  [[rel4.6:annotation_processor_configuration]]
   * You should not put annotation processors on the compile classpath or declare them with the `-processorpath` compiler argument.
  