RichVersionConstraintsIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove unnecessary @Unroll annotations from "dependencyManagement"

    • -5
    • +0
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 160 more files in changeset.
Remove unnecessary @Unroll annotations from "dependencyManagement"

    • -5
    • +0
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 160 more files in changeset.
Remove unnecessary @Unroll annotations from "dependencyManagement"

    • -5
    • +0
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 160 more files in changeset.
Remove unnecessary @Unroll annotations from "dependencyManagement"

    • -5
    • +0
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 160 more files in changeset.
Remove unnecessary @Unroll annotations from "dependencyManagement"

    • -5
    • +0
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 160 more files in changeset.
@RequiredFeature can be used as a repeated annotation

If used for a single feature, avoid annotation noise by not using the

composite annotation. This also avoids the confusion that the

@RequiredFeature annotation cannot be used independently

(no compile error but does not work).

I made the @RequiredFeatures annotation package-private as it is

only required by the compiler and the runner now.

Signed-off-by: Benjamin Muskalla <bmuskalla@gradle.com>

    • -4
    • +2
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 43 more files in changeset.
@RequiredFeature can be used as a repeated annotation

If used for a single feature, avoid annotation noise by not using the

composite annotation. This also avoids the confusion that the

@RequiredFeature annotation cannot be used independently

(no compile error but does not work).

I made the @RequiredFeatures annotation package-private as it is

only required by the compiler and the runner now.

Signed-off-by: Benjamin Muskalla <bmuskalla@gradle.com>

    • -4
    • +2
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 43 more files in changeset.
Support '!!' short notation in dependency constraints

    • -0
    • +33
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 1 more file in changeset.
Remove trailing space in error message

And pay the price with tons of whitespace changes...

    • -23
    • +23
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 10 more files in changeset.
Remove trailing space in error message

And pay the price with tons of whitespace changes...

    • -23
    • +23
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 9 more files in changeset.
Remove trailing space in error message

And pay the price with tons of whitespace changes...

    • -23
    • +23
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 10 more files in changeset.
Remove trailing space in error message

And pay the price with tons of whitespace changes...

    • -23
    • +23
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 10 more files in changeset.
Remove trailing space in error message

And pay the price with tons of whitespace changes...

    • -23
    • +23
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 10 more files in changeset.
Remove trailing space in error message

And pay the price with tons of whitespace changes...

    • -23
    • +23
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 10 more files in changeset.
Introduce shorthand notation for strict versions

This commit introduces a modifier (!!) that can be

used in version strings to introduce a strict version.

For example, the following notation:

org:foo:1.0!!

is equivalent to:

version { strictly '1.0' }

And this notation:

org:foo:[1.0,2.0]!!1.5

is equivalent to:

version {

strictly '[1.0, 2.0]'

prefer '1.5'

}

    • -16
    • +3
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 2 more files in changeset.
Introduce shorthand notation for strict versions

This commit introduces a modifier (!!) that can be

used in version strings to introduce a strict version.

For example, the following notation:

org:foo:1.0!!

is equivalent to:

version { strictly '1.0' }

And this notation:

org:foo:[1.0,2.0]!!1.5

is equivalent to:

version {

strictly '[1.0, 2.0]'

prefer '1.5'

}

    • -16
    • +3
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 2 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).

    • -132
    • +112
    ./RichVersionConstraintsIntegrationTest.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).

    • -132
    • +112
    ./RichVersionConstraintsIntegrationTest.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).

    • -132
    • +112
    ./RichVersionConstraintsIntegrationTest.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).

    • -132
    • +112
    ./RichVersionConstraintsIntegrationTest.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).

    • -132
    • +112
    ./RichVersionConstraintsIntegrationTest.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).

    • -132
    • +112
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 77 more files in changeset.
Sort module selectors

This commit reworks module selectors so that they are sorted

in an order which reduces the cost of module selection. We

make sure to put local (project) selectors first, then we

use selectors from locks (if any).

The next selectors are "latest" version selectors because

even if they are dynamic, they are likely to "win" selection.

Then, exact version selectors are sorted by version descending

, and last we add dynamic version selectors.

    • -1
    • +1
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 19 more files in changeset.
Sort module selectors

This commit reworks module selectors so that they are sorted

in an order which reduces the cost of module selection. We

make sure to put local (project) selectors first, then we

use selectors from locks (if any).

The next selectors are "latest" version selectors because

even if they are dynamic, they are likely to "win" selection.

Then, exact version selectors are sorted by version descending

, and last we add dynamic version selectors.

    • -1
    • +1
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 19 more files in changeset.
Sort module selectors

This commit reworks module selectors so that they are sorted

in an order which reduces the cost of module selection. We

make sure to put local (project) selectors first, then we

use selectors from locks (if any).

The next selectors are "latest" version selectors because

even if they are dynamic, they are likely to "win" selection.

Then, exact version selectors are sorted by version descending

, and last we add dynamic version selectors.

    • -1
    • +1
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 19 more files in changeset.
Sort module selectors

This commit reworks module selectors so that they are sorted

in an order which reduces the cost of module selection. We

make sure to put local (project) selectors first, then we

use selectors from locks (if any).

The next selectors are "latest" version selectors because

even if they are dynamic, they are likely to "win" selection.

Then, exact version selectors are sorted by version descending

, and last we add dynamic version selectors.

    • -1
    • +1
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 19 more files in changeset.
Sort module selectors

This commit reworks module selectors so that they are sorted

in an order which reduces the cost of module selection. We

make sure to put local (project) selectors first, then we

use selectors from locks (if any).

The next selectors are "latest" version selectors because

even if they are dynamic, they are likely to "win" selection.

Then, exact version selectors are sorted by version descending

, and last we add dynamic version selectors.

    • -1
    • +1
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 19 more files in changeset.
Fix tests for change to constraint error reporting

    • -1
    • +1
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 1 more file in changeset.
Include unattached dependencies when reporting unresolvable dependency

Fixes #5573

    • -0
    • +34
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 1 more file in changeset.
Remove custom rendering when building failure message

For consistency, we now use `ComponentSelector.displayName` when

rendering a failure message, instead of custom display logic.

    • -8
    • +8
    ./RichVersionConstraintsIntegrationTest.groovy
  1. … 6 more files in changeset.