DefaultImmutableVersionConstraintTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename inheritStrictVersions() -> endorseStrictVersions() (#10755)

This name change more clearly communicates the semantics of the

feature from a users point of view.

This commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

would have been misleading in the future. To make sure we catch all,

this also updates all variable/method/package names.

    • -5
    • +4
    ./DefaultImmutableVersionConstraintTest.groovy
  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

    • -5
    • +4
    ./DefaultImmutableVersionConstraintTest.groovy
  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

    • -5
    • +4
    ./DefaultImmutableVersionConstraintTest.groovy
  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

    • -5
    • +4
    ./DefaultImmutableVersionConstraintTest.groovy
  1. … 70 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).

    • -17
    • +12
    ./DefaultImmutableVersionConstraintTest.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).

    • -17
    • +12
    ./DefaultImmutableVersionConstraintTest.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).

    • -17
    • +12
    ./DefaultImmutableVersionConstraintTest.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).

    • -17
    • +12
    ./DefaultImmutableVersionConstraintTest.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).

    • -17
    • +12
    ./DefaultImmutableVersionConstraintTest.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).

    • -17
    • +12
    ./DefaultImmutableVersionConstraintTest.groovy
  1. … 77 more files in changeset.
Add `forSubgraph()` API to version constraints

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

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

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

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

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

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

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

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

    • -1
    • +1
    ./DefaultImmutableVersionConstraintTest.groovy
  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
    ./DefaultImmutableVersionConstraintTest.groovy
  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

difference.

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

    • -1
    • +2
    ./DefaultImmutableVersionConstraintTest.groovy
  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
    ./DefaultImmutableVersionConstraintTest.groovy
  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
    ./DefaultImmutableVersionConstraintTest.groovy
  1. … 6 more files in changeset.
Add code coverage for `DefaultImmutableVersionConstraint`

Issue #3305

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