capabilities

In general conflict detection for implicit capabilities is skipped

for performance optimization. However, if the corresponding capability

is explicitly declared by another component that was visited *before*,

we need to do the conflict detection between the component with

the implicit capability and the one visited earlier.

See also: #11300

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

This commit disables the automatic capability conflict

resolution based on the highest version of a capability

and replaces it with a customizable resolution strategy.

This allows better control on how capability conflicts

are handled: before this change, capabilities could be

automatically upgraded just because they had a higher

version, which is not always acceptable.

The new API gives finer control by providing a DSL on

the resolution strategy which allows:

- explicitly setting "highest wins" strategy for a given

capability

- or choosing explicitly between a list of modules in conflict

for a given capability

It is possible to use a generic _all_ call to configure the

strategy independently of the capability.

Closes #9888

This commit disables the automatic capability conflict

resolution based on the highest version of a capability

and replaces it with a customizable resolution strategy.

This allows better control on how capability conflicts

are handled: before this change, capabilities could be

automatically upgraded just because they had a higher

version, which is not always acceptable.

The new API gives finer control by providing a DSL on

the resolution strategy which allows:

- explicitly setting "highest wins" strategy for a given

capability

- or choosing explicitly between a list of modules in conflict

for a given capability

It is possible to use a generic _all_ call to configure the

strategy independently of the capability.

Closes #9888

Now that we can have either `ImmutableCapability` or

`ProjectDerivedCapability` on a selector, they need to be able to do

cross equality checks.

Now that we can have either `ImmutableCapability` or

`ProjectDerivedCapability` on a selector, they need to be able to do

cross equality checks.

Now that we can have either `ImmutableCapability` or

`ProjectDerivedCapability` on a selector, they need to be able to do

cross equality checks.