resolutionstrategy

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 method is a short-hand notation to disable both use

of dynamic and changing versions.

This commit adds the `failOnChangingVersions()` method on

the resolution strategy, which will make the build fail as

soon as a changing version is detected.

This is useful to prevent, for example, snapshots from

appearing in a dependency graph.

This commit adds the `failOnChangingVersions()` method on

the resolution strategy, which will make the build fail as

soon as a changing version is detected.

This is useful to prevent, for example, snapshots from

appearing in a dependency graph.

This commit introduces a new dependency graph validation mode,

which will make sure that if dynamic versions are found in the

graph, then either they are superceded by another version (they

don't participate in selection) or the build should fail.

This means that, for example, if a version selector uses a

version range `[1.0, 2.0[`, the build will fail because in a

subsequent build the resolution may change.

However, if there are two selectors participating, say

`[1.0, 2.0[` and `1.5`, then we choose `1.5` because this version

is within the range. Even if newer versions are released, we

would _not_ change the resolution result.

Previous parameters are available on `ComponentSelection` instead.

Previous parameters are available on `ComponentSelection` instead.

Previous parameters are available on `ComponentSelection` instead.

Previous parameters are available on `ComponentSelection` instead.

Previous parameters are available on `ComponentSelection` instead.

Previous parameters are available on `ComponentSelection` instead.

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