Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Add `forSubgraph()` API to version constraints

    • -11
    • +28
  1. … 20 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -11
    • +28
  1. … 19 more files in changeset.
Add `strong()` API to version constraints

    • -10
    • +10
  1. … 16 more files in changeset.
Provide special display message for 'reject all'

    • -0
    • +1
  1. … 4 more files in changeset.
Add useful displayName to `VersionConstraint`

    • -0
    • +22
  1. … 3 more files in changeset.
Don't implicitly add 'prefer' with 'require'

    • -1
    • +1
  1. … 11 more files in changeset.
Ensure that 'preferredVersion' always provides a useful value

Recent versions of the build scan plugin depend on `VersionConstraint.preferredVersion`

to return a string representation of the version constraint. This was broken with the

recent introduction of `requiredVersion`, where `preferredVersion` only returned a

value when explicitly set with `prefers(version)`.

This change restores the previous functionality: a `requires` version constraint implies

a `prefers` constraint, and a `strictly` constraint implies a `requires` constraint.

    • -8
    • +8
  1. … 18 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


    • -13
    • +24
  1. … 36 more files in changeset.
Simplify construction of DefaultMutableVersionConstraint

    • -1
    • +2
  1. … 6 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)

    • -12
    • +15
  1. … 25 more files in changeset.
Ensure MutableVersionConstraint does not have null preferredVersion

While the interface for `VersionConstraint` declared that version was

`@Nullable`, in reality we prevented this when constructing an immutable

version constraint. This meant that `MutableVersionConstraint.asImmutable()`

converted null values to empty strings.

This changes the contract so that `VersionConstraint.preferredVersion` is no

longer `@Nullable`, and an empty string is consistently used to define a

'missing' preferred version, for all implementations of `VersionConstraint`.

    • -0
    • +33
  1. … 6 more files in changeset.
Add code coverage for `DefaultImmutableVersionConstraint`

Issue #3305

    • -0
    • +101
  1. … 1 more file in changeset.