anchor.diff:  [[sec:debugging-build-scans]]
   == Build scans
   
  -TODO: more context about build scans
  +[NOTE]
  +====
  +If you do not know what link:https://scans.gradle.com/[build scan]s are, be sure to check them out!
  +====
   
  -A link:https://scans.gradle.com/[build scan] can visualize dependencies as a navigable, searchable tree.
  +A build scan can visualize dependencies as a navigable, searchable tree.
   Additional context information can be rendered by clicking on a specific dependency in the graph.
   
   .Dependency tree in a build scan
  
positive.code: include::{samplesPath}/userguide/dependencyManagement/inspectingDependencies/dependencyInsightReport/dependencyInsightReport.out[]
  ----
  
  [[sec:resolving-variant-aware-errors]]
  == Resolving variant selection errors
  
  
negative.code: Large software projects inevitably deal with an increased number of dependencies either through direct or transitive dependencies.
  The <<#sec:listing_dependencies,dependencies report>> provides you with the raw list of dependencies but does not explain _why_ they have been selected or _which_ dependency is responsible for pulling them into the graph.
  
  Let's have a look at a concrete example.
  A project may request two different versions of the same dependency either as direct or transitive dependency.
  Gradle applies <<dependency_resolution.adoc#sec:version-conflict,version conflict resolution>> to ensure that only one version of the dependency exists in the dependency graph.
  In this example the conflicting dependency is represented by `commons-codec:commons-codec`.
  
  .Declaring the JGit dependency and a conflicting dependency
  