anchor.diff:  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 version conflict resolution to ensure that only one version of the dependency exists in the dependency 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
  
positive.code: 
  [[sub:no-matching-variant-errors]]
  === No matching variants
  
  
  [[sub:solving-capability-conflicts]]
  === Solving capability conflicts
  
  By default, Gradle will automatically choose the component with the highest version of a capability.
  This can be useful whenever a component is relocated at different coordinates in a new release.
  For example, the ASM library lived at `asm:asm` coordinates until version `3.3.1`, then changed to `org.ow2.asm:asm` since `4.0`.
  It is illegal to have both ASM <=3.3.1 and 4.0+ on the classpath, because they provide the same feature, it's just that the component has been relocated.
  Because each component has an implicit capability corresponding to its GAV coordinates, we can fix this by having a rule that will declare that the `asm:asm` module provides the `org.ow2.asm:asm` capability:
  
  .Automatic conflict resolution by capability versioning
  ====
  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/declaringCapabilities/groovy",files="build.gradle[tags=fix_asm]"]
  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/declaringCapabilities/kotlin",files="build.gradle.kts[tags=fix_asm]"]
  ====
  
  However, fixing by automatic capability version conflict resolution is not always suitable.
  In our logging example, it doesn't matter what version of the logging frameworks we use, we should always select the slf4j bridge.
  
  In this case, we can fix it by using dependency substitution:
  
  .Substitute log4j with slf4j
  ====
  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/declaringCapabilities/groovy",files="build.gradle[tags=replacement_rule]"]
  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/declaringCapabilities/kotlin",files="build.gradle.kts[tags=replacement_rule]"]
  ====
  
  TODO: BELOW OLD CONTENT TO BE RESHUFFLED
  
  [[sec:version-conflicts]]
  == Resolving version conflicts
  
  Gradle resolves version conflicts by picking the highest version of a module. link:https://scans.gradle.com/get-started[Build scans] and the <<#sec:identifying_reason_dependency_selection,dependency insight report>> are immensely helpful in identifying why a specific version was selected. If the resolution result is not satisfying (e.g. the selected version of a module is too high) or it fails (because you configured link:{groovyDslPath}/org.gradle.api.artifacts.ResolutionStrategy.html#org.gradle.api.artifacts.ResolutionStrategy:failOnVersionConflict()[ResolutionStrategy.failOnVersionConflict()]) you have the following possibilities to fix it.
  
  * Configuring any dependency (transitive or not) as _forced_. This approach is useful if the dependency in conflict is a transitive dependency. See <<controlling_transitive_dependencies.adoc#sec:enforcing_dependency_version,Enforcing a particular dependency version>> for examples.
  * Configuring dependency resolution to _prefer modules that are part of your build_ (transitive or not). This approach is useful if your build contains custom forks of modules (as part of <<multi_project_builds.adoc#multi_project_builds,multi-project builds>> or as include in <<composite_builds.adoc#,composite builds>>). See link:{groovyDslPath}/org.gradle.api.artifacts.ResolutionStrategy.html#org.gradle.api.artifacts.ResolutionStrategy:preferProjectModules()[ResolutionStrategy.preferProjectModules()] for more information.
  * Using <<controlling_transitive_dependencies.adoc#sec:dependency_resolve_rules,dependency resolve rules>> for fine-grained control over the version selected for a particular dependency.
  
  [[sec:locking_dependency_versions]]
  == Locking dependency versions
  
  The use of <<declaring_dependency_versions.adoc#sub:declaring_dependency_with_dynamic_version,dynamic dependencies>> in a build is convenient.
  The user does not need to know the latest version of a dependency and Gradle automatically uses new versions once they are published.
  However, dynamic dependencies make builds non-reproducible, as they can resolve to a different version at a later point in time.
  This makes it hard to reproduce old builds when debugging a problem.
  It can also disrupt development if a new, but incompatible version is selected.
  In the best case the CI build catches the problem and someone needs to investigate.
  In the worst case, the problem makes it to production unnoticed.
  
  Gradle offers <<dependency_locking.adoc#,dependency locking>> to solve this problem.
  The user can run a build asking to persist the resolved versions for every module dependency.
  This file is then checked in and the versions in it are used on all subsequent runs until the lock is updated or removed again.
  
  [[sec:versioning_file_dependencies]]
  == Versioning of file dependencies
  
  Legacy projects sometimes prefer to consume <<declaring_dependencies.adoc#sub:file_dependencies,file dependencies>> instead of <<declaring_dependencies.adoc#sub:module_dependencies,module dependencies>>.
  File dependencies can point to any file in the filesystem and do not need to adhere a specific naming convention.
  It is recommended to clearly express the intention and a concrete version for file dependencies.
  File dependencies are not considered by Gradle's <<dependency_resolution.adoc#sec:how-gradle-downloads-deps,version conflict resolution>>.
  Therefore, it is extremely important to assign a version to the file name to indicate the distinct set of changes shipped with it.
  For example `commons-beanutils-1.3.jar` lets you track the changes of the library by the release notes.
  
  As a result, the dependencies of the project are easier to maintain and organize. It's much easier to uncover potential API incompatibilities by the assigned version.
  
  [[sec:configuration_resolution_constraints]]
  == Constraints on configuration resolution
  
  Configurations need to be resolved safely when crossing project boundaries because resolving configurations can have side effects on Gradle's project model. Gradle can usually manage this safe access, but the configuration needs to be accessed in a way that enables Gradle to do so. There are a number of ways a configuration might be resolved unsafely and Gradle will produce a deprecation warning for each unsafe access.
  
  For example:
  
  * A task from one project directly resolves a configuration in another project.
  * A task specifies a configuration from another project as an input file collection.
  * A build script for a project resolves a configuration in another project during evaluation.
  * A configuration is resolved in a user-managed thread (i.e., a thread not managed by Gradle).
  
  If your build has an unsafe access deprecation warning, it needs to be fixed.  It's a symptom of these bad practices and cause strange and indeterminate errors.
  
  More importantly, resolving a configuration from a user-managed thread is not supported.  To ensure that the configuration is resolved safely, it must be resolved in a Gradle-managed thread.  Afterwards, the resolution result can be used in user-managed threads.
  
  In most cases, the deprecation warning can be fixed by defining a configuration in the project where the resolution is occurring and setting it to link:{javadocPath}/org/gradle/api/artifacts/Configuration.html#extendsFrom-org.gradle.api.artifacts.Configuration++...++-[extend from] the configuration in the other project.
  
negative.code: [[sec:debugging-build-scans]]
  == 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 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
  