DefaultResolutionStrategySpec.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add `failOnNonReproducibleResolution`

This method is a short-hand notation to disable both use

of dynamic and changing versions.

    • -0
    • +3
    ./DefaultResolutionStrategySpec.groovy
  1. … 8 more files in changeset.
Add `failOnNonReproducibleResolution`

This method is a short-hand notation to disable both use

of dynamic and changing versions.

    • -0
    • +3
    ./DefaultResolutionStrategySpec.groovy
  1. … 8 more files in changeset.
Add support for failing on 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.

    • -0
    • +5
    ./DefaultResolutionStrategySpec.groovy
  1. … 5 more files in changeset.
Add support for failing on 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.

    • -0
    • +5
    ./DefaultResolutionStrategySpec.groovy
  1. … 5 more files in changeset.
Introduce `failOnDynamicVersion`

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.

    • -0
    • +7
    ./DefaultResolutionStrategySpec.groovy
  1. … 8 more files in changeset.
Introduce `failOnDynamicVersion`

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.

    • -0
    • +7
    ./DefaultResolutionStrategySpec.groovy
  1. … 8 more files in changeset.
Add support for deactivateDependencyLocking to disable locking on configurations

Signed-off-by: Roberto Perez Alcolea <rperezalcolea@netflix.com>

    • -0
    • +8
    ./DefaultResolutionStrategySpec.groovy
  1. … 12 more files in changeset.
Add customizable capability conflict resolution

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

    • -1
    • +1
    ./DefaultResolutionStrategySpec.groovy
  1. … 19 more files in changeset.
Add customizable capability conflict resolution

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

    • -1
    • +1
    ./DefaultResolutionStrategySpec.groovy
  1. … 19 more files in changeset.
Add customizable capability conflict resolution

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

    • -1
    • +1
    ./DefaultResolutionStrategySpec.groovy
  1. … 19 more files in changeset.
Renamed `VersionSelectionReasons` -> `ComponentSelectionReasons`

    • -3
    • +3
    ./DefaultResolutionStrategySpec.groovy
  1. … 30 more files in changeset.
Simplify construction of ModuleVersionSelector in unit tests

    • -4
    • +4
    ./DefaultResolutionStrategySpec.groovy
  1. … 13 more files in changeset.
Normalize `ModuleIdentifier`

This commit reworks the `ComponentModuleIdentifier`/`ComponentModuleSelector`/`ModuleVersionSelector`

classes to use `ModuleIdentifier` under the hood, instead of storing denormalized strings. This has

the advantage that we can reduce the use of the module identifier factory, which is called very

often during dependency resolution. Sharing instances reduces the need for conversions, and makes

comparisons faster.

    • -6
    • +8
    ./DefaultResolutionStrategySpec.groovy
  1. … 164 more files in changeset.
Revert changes from PR5628

This reverts the following commits:

10a25358953dfb28b09cf04356945517d5cc560e

54d19a74ab2d29673219d9c6d27388b93c55eada

d0eb19dbf28df1a108742ba177eda56301e1fab4

dcf5f65b49db17fb625ecab7498b060ab8191b9b

99847ad25f9e0ab7b1f65beb976dcb59cbadd1b9

f2f412141e1ab29e0cfafc72fd962ae645508720

99b45c8d7f0e94d2d41c43c731ca1329d6f07606

    • -2
    • +2
    ./DefaultResolutionStrategySpec.groovy
  1. … 40 more files in changeset.
Removed `ModuleVersionSelector.versionConstraint`

- Pushed `getVersionConstraint()` down to `ExternalDependency` and

`DependencyConstraint`

- Only use a single version string when constructing `ModuleVersionSelector`

    • -2
    • +2
    ./DefaultResolutionStrategySpec.groovy
  1. … 19 more files in changeset.
Removed `ModuleVersionSelector.versionConstraint`

- Pushed `getVersionConstraint()` down to `ExternalDependency` and

`DependencyConstraint`

- Only use a single version string when constructing `ModuleVersionSelector`

    • -2
    • +2
    ./DefaultResolutionStrategySpec.groovy
  1. … 19 more files in changeset.
Lock validation and persist through graph visitor

This introduces validation of graph resolution with the lock file.

Added or missing dependencies in the graph compared to the lock

file cause a failure.

The visitor doing the validation is also used for trigerring

the persistence of the result.

Fixes #4862

    • -1
    • +22
    ./DefaultResolutionStrategySpec.groovy
  1. … 28 more files in changeset.
Introduced a service that determines the VCS to use to locate matches for a particular component selector, to allow this logic to be reused by the things that need this information rather than duplicating it in several places, and to decouple these consumers from the details of how the decision is made.

    • -3
    • +4
    ./DefaultResolutionStrategySpec.groovy
  1. … 10 more files in changeset.
Prefer source dependency rules in the root project over rules in nested projects

    • -2
    • +2
    ./DefaultResolutionStrategySpec.groovy
  1. … 16 more files in changeset.
Add service to provide ModuleVersionSelector for ComponentSelector

Instead of having the target `ModuleVersionSelector` travel with the dependency metadata,

we rely on `ComponentSelector` for a dependency, and only lookup the related module or

`ModuleVersionSelector` when actually required.

The logic to determine a `ModuleVersionSelector` from `ComponentSelector` is:

- For ModuleComponentSelector, convert directly

- For ProjectComponentSelector, lookup coordinates of target project

The new service is used to replace the following uses of `DependencyMetadata.requested`:

- To produce the details object provided to `eachDependency` (exposes ModuleVersionSelector)

- To produce `UnresolvedDependency` instances for `ResolvedConfiguration`

    • -2
    • +4
    ./DefaultResolutionStrategySpec.groovy
  1. … 26 more files in changeset.
Rename `DefaultVersionConstraint` to `DefaultMutableVersionConstraint`

... and use the immutable version whenever possible.

    • -7
    • +7
    ./DefaultResolutionStrategySpec.groovy
  1. … 63 more files in changeset.
Make `ModuleComponentSelector` the source of truth for version constraints

This commit pushes `VersionConstraint` as a primary concept in `ModuleComponentSelector`. It replaces the (now)

deprecated `getVersion` call, which didn't reflect all possible constraints on a version. This change has several

consequences:

- version constraints now need to be "serializable"

- version constraints now consist of a preferred version and a list of rejected versions

- only a single item in the rejection list is supported

- Gradle module metadata parsing now generates a prefer/reject list

- Gradle module metadata writing does **not** yet support writing prefer/reject

- the module metadata binary format has been bumped to support prefer/reject in module descriptors

- metadata rules can say `useTarget(VersionConstraint)`

Issue #3312

    • -6
    • +7
    ./DefaultResolutionStrategySpec.groovy
  1. … 93 more files in changeset.
Turn `ConflictResolution` into an enum

The previous implemention was an adhoc enum, using an interface and concrete

classes. Probably code written pre-enum era.

    • -1
    • +2
    ./DefaultResolutionStrategySpec.groovy
  1. … 6 more files in changeset.
Add VCS mapping API

Incorporate upstream changes

    • -2
    • +5
    ./DefaultResolutionStrategySpec.groovy
  1. … 38 more files in changeset.
Pass the module identifier factory down to module forcing resolve rule

    • -1
    • +8
    ./DefaultResolutionStrategySpec.groovy
  1. … 11 more files in changeset.
Provide global substitution rules when constructing DefaultConfiguration

Instead of wiring in the global dependency substitution rules later in

resolution, they are now provided directly to the ResolutionStrategy

when constructing a DefaultConfiguration. This allows the automatic

detection of 'fluid dependencies' to function correctly.

    • -3
    • +7
    ./DefaultResolutionStrategySpec.groovy
  1. … 17 more files in changeset.
Fix failing tests

+review REVIEW-5952

    • -1
    • +1
    ./DefaultResolutionStrategySpec.groovy
  1. … 3 more files in changeset.
Moved classes related to dependency substitution into a separate package

    • -0
    • +1
    ./DefaultResolutionStrategySpec.groovy
  1. … 28 more files in changeset.
Don’t hard-code component selector subtypes in DependencySubstitutionResolver

    • -6
    • +8
    ./DefaultResolutionStrategySpec.groovy
  1. … 19 more files in changeset.
Renamed ‘beforeChange’ to ‘setMutationValidator’ in a few cases

+review REVIEW-5438

    • -2
    • +2
    ./DefaultResolutionStrategySpec.groovy
  1. … 10 more files in changeset.