anchor.diff:  include::sample[dir="snippets/userguide/dependencyManagement/attributeMatching/snippets/kotlin",files="build.gradle.kts[tags=concrete-classpath]"]
   ====
   
  -At this stage, we have 3 different configurations, which already have different goals:
  -
  -- `someConfiguration` declares the dependencies of my application. It's just a bucket where we declare a list of dependencies.
  -- `compileClasspath` and `runtimeClasspath` are configurations _meant to be resolved_: when resolved they should contain respectively the compile classpath, and the runtime classpath of the application.
  -
  -This is actually represented on the `Configuration` type by the `canBeResolved` flag.
  +At this point, we have 3 different configurations with different roles:
  +
  +- `someConfiguration` declares the dependencies of my application. It's just a bucket that can hold a list of dependencies.
  +- `compileClasspath` and `runtimeClasspath` are configurations _meant to be resolved_: when resolved they should contain the compile classpath, and the runtime classpath of the application respectively.
  +
  +This distinction is represented by the `canBeResolved` flag in the `Configuration` type.
   A configuration that _can be resolved_ is a configuration for which we can compute a dependency graph, because it contains all the necessary information for resolution to happen.
   That is to say we're going to compute a dependency graph, resolve the components in the graph, and eventually get artifacts.
   A configuration which has `canBeResolved` set to `false` is not meant to be resolved.
  
positive.code: [[sec:resolvable-consumable-configs]]
  == Resolvable and consumable configurations
  
  Historically, configurations have been at the root of dependency resolution in Gradle.
  In the end, what we want to make a difference is between a _consumer_ and a _producer_. For this purpose, configurations are used for at least 3 different aspects:
  
  1. to declare dependencies
  2. as a _consumer_, to resolve a set of dependencies to files
  3. as a _producer_, to expose artifacts and their dependencies for consumption by other projects
     (such _consumable_ configurations usually represent the <<variant_model.adoc#,variants>> the producer offers to its consumers)
  
  For example, if I want to express that my application `app` _depends on_ library `lib`, we need _at least_ one configuration:
  
  .Configurations are used to declare dependencies
  ====
  
negative.code: The reason is that depending on the usage (compile classpath, runtime classpath), it _can_ resolve to different graphs.
  It is an error to try to resolve a configuration which has `canBeResolved` set to `false`.
  To some extent, this is similar to an _abstract class_ (`canBeResolved`=false) which is not supposed to be instantiated, and a concrete class extending the abstract class (`canBeResolved`=true).
  A resolvable configuration will extend at least one non-resolvable configuration (and may extend more than one).
  
  On the other end, at the library project side (the _producer_), we also use configurations to represent what can be consumed.
  For example, the library may expose an API or a runtime, and we would attach artifacts to either one, the other, or both.
  Typically, to compile against `lib`, we need the API of `lib`, but we don't need its runtime dependencies.
  So the `lib` project will expose an `apiElements` configuration, which is aimed at consumers looking for its API.
  Such a configuration is consumable, but is not meant to be resolved.
  This is expressed via the _canBeConsumed_ flag of a `Configuration`:
  
  .Setting up configurations
  