DefaultResolvedVersionConstraintTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Inject FeaturePreviews in DefaultVersionComparator

This will enable to select which StaticVersionComparator to use based on

feature preview activation.

As a consequence, the VersionComparator becomes build scoped and has to

be injected instead of being instantiated in different places.

Issue #13050

    • -1
    • +2
    ./DefaultResolvedVersionConstraintTest.groovy
  1. … 26 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.

    • -18
    • +10
    ./DefaultResolvedVersionConstraintTest.groovy
  1. … 5 more files in changeset.
Support a dependency with both `require` and `prefer` versions

    • -1
    • +2
    ./DefaultResolvedVersionConstraintTest.groovy
  1. … 14 more files in changeset.
Separate 'prefer' and 'require' in dependency versions

When we introduced the ability to declare a 'preferred' version on

a dependency declaration, this was implemented such that declaring

a "required" dependency version using `org:foo:1.0` was effectively

the same as declaring a "preferred" version `org:foo { prefer '1.0' }`.

In order to differentiate between the behaviour of required and

preferred dependency versions, this commit introduces a separate

model for these constraint types. This model is published to

Gradle `.module` metadata files, and is retained internally

throughout dependency resolution.

At this stage, the behaviour of required and preferred versions

is identical. A later commit will introduce the behavioural

difference.

    • -2
    • +2
    ./DefaultResolvedVersionConstraintTest.groovy
  1. … 36 more files in changeset.
Strict constraints now reject both lower and higher versions

A strict version constraint is implemented by preferring any version in the

declared range, and rejecting other versions. Rejecting of lower versions happens

naturally through the `LatestModuleConflictResolver`.

With this change, the rejection of lower versions becomes explicit, instead of

building a range higher than a strict constraint and rejecting that, we instead

create a 'inverted' VersionSelector that will matches the exact complement of

the `strictly` version selector, and reject that.

This change will later permit us to remove the implicit 'reject all lower'

constraint in our resolution engine.

Strict version constraints are now rendered as 'strictly' in error messages.

    • -5
    • +7
    ./DefaultResolvedVersionConstraintTest.groovy
  1. … 9 more files in changeset.
Retain separate versions for 'strictly' and 'prefers'

Previously, a `strictly` version constraint was translated into a separate

'prefer' and 'reject' constraint: this is how it was processed internally,

as well as how it was represented in a `.module` file.

With this change, strict version constraints are logically retained as a

first class version constraint:

- `.module` files can have versions declared with `strictly`

- Strict constraints are only translated to a reject version selector

as part of resolution (not when parsing the constraint)

    • -0
    • +60
    ./DefaultResolvedVersionConstraintTest.groovy
  1. … 25 more files in changeset.