Extensible disambiguation rules

[melix]

Context

We knew the problem existed, but it has been highlighted by a fix for the Scala compiler by @big-guy . Whenever the Java plugin is applied, it adds a disambiguation rule, which role is to help selecting the right variant of a Java component, whenever multiple candidates are available.

The problem arises when a plugin wants to enrich the existing model. This is what the Scala plugin does. In addition to the JAVA_API and JAVA_RUNTIME usages, it adds a new one, an "incremental analysis" usage, that the Scala compiler deals with. It's worth noting that the Scala plugin builds on top of the Java plugin.

The problem, now, is that the default Java disambiguation rule is not capable of dealing with this new additional possible value for the Usage attribute. Therefore, the only option is that the Scala plugin adds another disambiguation rule which replicates what the Java disambiguation rule provides, but knowing that there's an additional possible value in the mix.

Note that we discussed using a separate attribute for this (other than Usage) since this seems orthogonal to the Usage, but it doesn't really solve the problem: while we have disambiguation rules for individual attributes, there's no such thing as a "global" disambiguation rule, which is able to select between multiple candidate variants, on different attributes.

See #6754

[big-guy]

We're suffering from this in the gradle/gradle build ourselves:

> Could not resolve all files for configuration ':core:integTestRuntime'.
   > Could not resolve project :docs.
     Required by:
         project :core > project :internalIntegTesting > project :launcher
         project :core
      > Cannot choose between the following variants of project :docs:
          - apiElements
          - cssElements
          - runtimeElements
        All of them match the consumer attributes:
          - Variant 'apiElements':
              - Found minified 'true' but wasn't required.
              - Found org.gradle.usage 'java-api' but wasn't required.
          - Variant 'cssElements':
              - Found minified 'true' but wasn't required.
              - Found org.gradle.usage 'css-resources' but wasn't required.
          - Variant 'runtimeElements':
              - Found minified 'true' but wasn't required.
              - Found org.gradle.usage 'java-runtime-jars' but wasn't required.

This makes gradle dependencies on our subprojects report failed dependencies on some configurations. In the docs project, we have a "css-resources" usage for exposing the css files elsewhere.

This is going to get worse if we convert our test fixtures to use this same mechanism.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[stale]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.