anchor.diff:  == Handling mutually exclusive variants
   
   The main advantage of using _capabilities_ as a way to handle features is that you can precisely handle compatibility of variants.
  -The rule is simple: it's not allowed to have two variants of components that provide the same capability in a dependency graph.
  +The rule is simple:
  +
  +> It's not allowed to have two variants of components that provide the same capability in a single dependency graph.
   
   We can leverage that to ask Gradle to fail whenever the user mis-configures dependencies.
   Imagine, for example, that your library supports MySQL, Postgres and MongoDB, but that it's only allowed to choose _one_ of those at the same time.
  
positive.code: ====
  As mentioned earlier, feature variants can be lossy when published.
  As a consequence, a consumer can depend on a feature variant only in two cases:
  - with a project dependency (in a multi-project build)
  - with Gradle metadata enabled (the publisher MUST have published using Gradle metadata)
  ====
  
negative.code: include::sample[dir="java-feature-variant/requiring-features/kotlin/consumer",files="build.gradle.kts[tags=consumer]"]
  ====
  
  This will automatically bring the `mysql-connector-java` dependency on runtime classpath.
  If there were more than one dependencies, all of them would be brought, meaning that a feature can be used to group dependencies which contribute to a feature together.
  
  Similarly, if the experimental Gradle metadata feature is enabled, it is possible to depend on an external dependency providing feature variants:
  
  .Consuming specific features from an external repository
  