DefaultMutableVersionConstraintTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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).

    • -24
    • +0
    ./DefaultMutableVersionConstraintTest.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).

    • -24
    • +0
    ./DefaultMutableVersionConstraintTest.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).

    • -24
    • +0
    ./DefaultMutableVersionConstraintTest.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).

    • -24
    • +0
    ./DefaultMutableVersionConstraintTest.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).

    • -24
    • +0
    ./DefaultMutableVersionConstraintTest.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).

    • -24
    • +0
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 77 more files in changeset.
Add MutableVersionConstraint.notForSubgraph() DSL method

The main use case for this are component metadata rules.

    • -1
    • +11
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 3 more files in changeset.
Add MutableVersionConstraint.notForSubgraph() DSL method

The main use case for this are component metadata rules.

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

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

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

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

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

    • -0
    • +14
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 19 more files in changeset.
Maintain separate `prefer` and `require` versions for constraint

    • -41
    • +42
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 3 more files in changeset.
Don't implicitly add 'prefer' with 'require'

    • -5
    • +5
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 11 more files in changeset.
Add `MutableVersionConstraint.require(version)`

By default, a dependency like 'org:foo:1.0' defines a 'require' version

constraint.

With this change, it is also possible to set the 'required' version for

a dependency from within `Configuration.withDependencies` or a component

metadata rule. This brings 'require' on par with 'prefer' and 'strictly'

for the purposes of configuration.

    • -1
    • +29
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 4 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.

    • -5
    • +5
    ./DefaultMutableVersionConstraintTest.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.

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

    • -1
    • +1
    ./DefaultMutableVersionConstraintTest.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)

    • -34
    • +7
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 25 more files in changeset.
Improve readability of reject selectors for strict constraints

- Use Maven-style open ranges `(,)` instead of Ivy-style `],[`

- Concatenate multiple ranges with `&` instead of `-`

    • -7
    • +7
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 7 more files in changeset.
Revert changes from PR5628

This reverts the following commits:

10a25358953dfb28b09cf04356945517d5cc560e

54d19a74ab2d29673219d9c6d27388b93c55eada

d0eb19dbf28df1a108742ba177eda56301e1fab4

dcf5f65b49db17fb625ecab7498b060ab8191b9b

99847ad25f9e0ab7b1f65beb976dcb59cbadd1b9

f2f412141e1ab29e0cfafc72fd962ae645508720

99b45c8d7f0e94d2d41c43c731ca1329d6f07606

    • -7
    • +7
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 40 more files in changeset.
Improve readability of reject selectors for strict constraints

- Use Maven-style open ranges `(,)` instead of Ivy-style `],[`

- Concatenate multiple ranges with `&` instead of `-`

    • -7
    • +7
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 7 more files in changeset.
Improve readability of reject selectors for strict constraints

- Use Maven-style open ranges `(,)` instead of Ivy-style `],[`

- Concatenate multiple ranges with `&` instead of `-`

    • -7
    • +7
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 7 more files in changeset.
Add unit test to illustrate the behavior when an empty list of rejects is used

    • -0
    • +13
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 1 more file in changeset.
Implement `rejectAll` on mutable version constraint

This commit leverages the prefer/reject infrastructure of version constraints

to implement incompatible module constraints. Internally, the rejection

constraint is implemented as:

- prefer empty version (aka, tells no preference)

- reject `+` (which is "reject any version starting with an empty string")

    • -0
    • +13
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 8 more files in changeset.
Add a `reject` method to `MutableVersionConstraint`

This is the first step towards supporting rejected versions. It will allow the use of `reject` in the DSL,

but support is not complete yet.

    • -0
    • +44
    ./DefaultMutableVersionConstraintTest.groovy
  1. … 2 more files in changeset.
Add basic test coverage for `DefaultMutableVersionConstraint`

    • -0
    • +100
    ./DefaultMutableVersionConstraintTest.groovy