Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Support prefix and latest selectors in strictly

This was basically just about adding test coverage.

The assumed behavior is that `latest.release` would

accept _any_ version when used in a reject selector,

so that we can iterate on rejected versions until

we find a match.

    • -6
    • +6
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 5 more files in changeset.
Support prefix and latest selectors in strictly

This was basically just about adding test coverage.

The assumed behavior is that `latest.release` would

accept _any_ version when used in a reject selector,

so that we can iterate on rejected versions until

we find a match.

    • -6
    • +6
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 5 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -33
    • +89
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -33
    • +89
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 79 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -33
    • +89
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -33
    • +89
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -33
    • +89
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

    • -33
    • +89
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 77 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -1
    • +1
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 19 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -1
    • +1
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 19 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -1
    • +1
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 20 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -1
    • +1
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 20 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -1
    • +1
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 19 more files in changeset.
Add `strong()` API to version constraints

    • -1
    • +1
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 16 more files in changeset.
Remove initials from a couple of TODOs

    • -2
    • +2
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.
Remove initials from a couple of TODOs

    • -2
    • +2
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.
Consolidate test coverage

    • -4
    • +62
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.
Unit test coverage for resolving single selector

    • -0
    • +51
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.
Support a dependency with both `require` and `prefer` versions

    • -3
    • +4
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 14 more files in changeset.
Never do version range merging for 'prefer' selectors

When no 'require' version was set for a dependency, we were processing

a set of 'prefer' version constraints in the same way as a set of 'require'

version constraints: ie we were doing version range merging for these

'prefer' constraints. When any 'require' constraint was provided, we no

longer did this merging for 'prefer' constraints.

With this commit, we no longer do this special processing for 'prefer'

in the absence of 'require'. Prefer constraints are processed consistently,

choosing the highest preference that does not conflict with any require

constraint.

    • -4
    • +4
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.
Maintain separate `prefer` and `require` versions for constraint

    • -4
    • +2
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 3 more files in changeset.
Verify reduced conflict resolution with `prefer`

The improved implementation of `prefer` constraints reduced the cases

where conflict resolution is required during resolution. This commit

simply updates the test coverage to verify this.

Fixes #4181

    • -7
    • +12
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.
Fix handling of 'prefer' constraints

This commit fixes a bug that resulted in us giving too much weight

to 'prefer' constraints when combined with other constraints.

By resolving each prefer constraint and trying each result in turn

starting with the highest, the processing of prefer constraints is

now predictable and reasonable.

This work highlights the need for more work to clean up the way that

we resolve multiple selectors for a module. Instead of resolving each

selector independently and then attempting to merge the results, we

should be merging the selectors first (where possible), prior to

resolving. This would reduce unnecessary dynamic resolves in the

case where we have both a range constraint `[10, 12]` and a fixed

version constraint `11`. A good example of where this would benefit

would be dependency locking, where all version ranges are effectively

constrained to a single version.

    • -2
    • +4
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 2 more files in changeset.
More coverage for selector merging

    • -3
    • +44
    ./scenarios/VersionRangeResolveTestScenarios.groovy
Tests demonstrating inadequacies in current selector merging

    • -0
    • +11
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.
Test coverage for intersecting ranges

    • -0
    • +17
    ./scenarios/VersionRangeResolveTestScenarios.groovy
Revert "Support version range merging for '.+' selectors"

Includes additional test changes for coverage added after the initial

commit.

This reverts commit 26da3b84b581a22c7c825495ec1ba4ec45e1febf.

    • -2
    • +2
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 4 more files in changeset.
Update tests to be compatible with new behaviour of 'prefer'

    • -9
    • +5
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 2 more files in changeset.
Test for conflict resolution in multi-selector resolve

    • -18
    • +42
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.
Test resolution with empty version constraints

    • -3
    • +26
    ./scenarios/VersionRangeResolveTestScenarios.groovy
  1. … 1 more file in changeset.