anchor.diff:  include::sample[dir="userguide/dependencyManagement/managingTransitiveDependencies/declaringCapabilities/kotlin",files="build.gradle.kts[tags=use_slf4j]"]
   ====
   
  -=== Declaring component capabilities
  -
  -[[selecting-between-candidates]]
  -=== Selecting between candidates
  +Note that this approach works also well if you have multiple _Slf4j bindings_ on the classpath:
  +bindings are basically different logger implementations and you need only one.
  +However, the selected implementation may depend on the configuration being resolved.
  +For example, for tests, `slf4j-simple` may be enough but for production, `slf4-over-log4j` may be better.
  +
  +For more information, check out the link:{javadocPath}/org/gradle/api/artifacts/ResolutionStrategy.html#capabilitiesResolution[the capabilities resolution API].
   
   [[sec:module_replacement]]
  -==== Module replacement rules
  +=== Module replacement rules
  +
  +It is preferable to express module conflicts in terms of <<sec:capabilities, capabilities conflicts>>.
  +However, if there's no such rule declared or that you are working on versions of Gradle which do not support capabilities, Gradle provides tooling to work around those issues.
   
   Module replacement rules allow a build to declare that a legacy library has been replaced by a new one.
   A good example when a new library replaced a legacy one is the `google-collections` -&gt; `guava` migration.
  
positive.code: Intuitively, it means that if Gradle finds two components that provide the same thing on classpath, it's going to fail with an error indicating what modules are in conflict.
  In our example, it means that different bindings of a logging framework provide the same capability.
  
  ==== Capability coordinates
  
  A _capability_ is defined by a `(group, module, version)` triplet.
  Each component defines an implicit capability corresponding to its GAV coordinates (group, artifact, version).
  For example, the `org.apache.commons:commons-lang3:3.8` module has an implicit capability with group `org.apache.commons`, name `commons-lang3` and version `3.8`.
  It is important to realize that capabilities are _versioned_.
  
  ==== Solving capability conflicts
  
  By default, Gradle will fail if two components in the dependency graph provide the same capability.
  It is however possible to tell it to choose the component with the highest capability version instead, just like regular version conflict resolution provides.
  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:
  
  .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]"]
  ====
  
  And then we can say that we will solve the conflict by automatically choosing the component which has the highest capability version:
  
  .Conflict resolution by capability versioning
  ====
  
negative.code: [[fixing-bad-metadata]]
  == Fixing bad metadata
  
  include::component_metadata_rules.adoc[leveloffset=+2]
  
  