anchor.diff:  [[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:
  +Configurations are a fundamental part of dependency resolution in Gradle.
  +In the context of dependency resolution, it is useful to distinguish between a _consumer_ and a _producer_. Along these lines, configurations have at least 3 different roles:
   
   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:
  +For example, to express that an application `app` _depends on_ library `lib`, _at least_ one configuration is required:
   
   .Configurations are used to declare dependencies
   ====
  
positive.code: include::sample[dir="snippets/userguide/dependencyManagement/attributeMatching/snippets/kotlin",files="build.gradle.kts[tags=setup-configurations]"]
  ====
  
  In short, a configuration role is determined by the `canBeResolved` and `canBeConsumed` flag combinations:
  
  .Configuration roles
  |===
  
negative.code: include::sample[dir="snippets/userguide/dependencyManagement/attributeMatching/snippets/kotlin",files="build.gradle.kts[tags=declare-configuration]"]
  ====
  
  Configurations can inherit dependencies from other configurations by extending from them.
  Now, notice that the code above doesn't tell us anything about the intended _consumer_ of this configuration.
  In particular, it doesn't tell us how the configuration is meant to be _used_.
  Let's say that `lib` is a Java library: it might expose different things, such as its API, implementation, or test fixtures.
  It might be necessary to change how we resolve the dependencies of `app` depending upon the task we're performing (compiling against the API of `lib`, executing the application, compiling tests, etc.).
  To address this problem, you'll often find companion configurations, which are meant to unambiguously declare the usage:
  
  .Configurations representing concrete dependency graphs
  ====
  