Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Backport test fixture improvements from 6.0 branch

  1. … 2 more files in changeset.
Backport test fixture improvements from 6.0 branch

  1. … 2 more files in changeset.
Backport test fixture improvements from 6.0 branch

  1. … 2 more files in changeset.
Do not expect an exact number of HEAD requests

This seems to be dependent on timing. If one request starts after

another did already finish, it can take the result from cache.

  1. … 1 more file in changeset.
Do not expect an exact number of HEAD requests

This seems to be dependent on timing. If one request starts after

another did already finish, it can take the result from cache.

  1. … 1 more file in changeset.
Do not expect an exact number of HEAD requests

This seems to be dependent on timing. If one request starts after

another did already finish, it can take the result from cache.

  1. … 1 more file in changeset.
Do not expect an exact number of HEAD requests

This seems to be dependent on timing. If one request starts after

another did already finish, it can take the result from cache.

  1. … 1 more file in changeset.
Revert "Do not emit deprecation warning for deprecated 'force'"

This reverts commit 1db54192db6ef9af5c2fd6b227004eed9a27c07f.

    • -0
    • +3
    ./gradle/integtests/resolve/AbstractProjectDependencyConflictResolutionIntegrationSpec.groovy
  1. … 10 more files in changeset.
Do not emit deprecation warning for deprecated 'force'

Nagging for this deprecation will only start with 6.1 to ease

the migration from 'force' to 'strictly'.

    • -3
    • +0
    ./gradle/integtests/resolve/AbstractProjectDependencyConflictResolutionIntegrationSpec.groovy
  1. … 10 more files in changeset.
Do not emit deprecation warning for deprecated 'force'

Nagging for this deprecation will only start with 6.1 to ease

the migration from 'force' to 'strictly'.

    • -3
    • +0
    ./gradle/integtests/resolve/AbstractProjectDependencyConflictResolutionIntegrationSpec.groovy
  1. … 10 more files in changeset.
Deprecated `force` on first-level dependencies

This commit deprecates using `force` in favor of using the

new "strictly" behavior. The "force" flag is still used

internally, in particular in case of virtual platforms, but

its usage should be discouraged as we have a solution which

is better now.

    • -0
    • +3
    ./gradle/integtests/resolve/AbstractProjectDependencyConflictResolutionIntegrationSpec.groovy
  1. … 23 more files in changeset.
Deprecated `force` on first-level dependencies

This commit deprecates using `force` in favor of using the

new "strictly" behavior. The "force" flag is still used

internally, in particular in case of virtual platforms, but

its usage should be discouraged as we have a solution which

is better now.

    • -0
    • +3
    ./gradle/integtests/resolve/AbstractProjectDependencyConflictResolutionIntegrationSpec.groovy
  1. … 18 more files in changeset.
Deprecated `force` on first-level dependencies

This commit deprecates using `force` in favor of using the

new "strictly" behavior. The "force" flag is still used

internally, in particular in case of virtual platforms, but

its usage should be discouraged as we have a solution which

is better now.

    • -0
    • +3
    ./gradle/integtests/resolve/AbstractProjectDependencyConflictResolutionIntegrationSpec.groovy
  1. … 23 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.

  1. … 5 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.

  1. … 5 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).

  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).

  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).

  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).

  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).

  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).

  1. … 77 more files in changeset.
Add test for classifier selection behavior if provider publishes GMM

  1. … 2 more files in changeset.
Extend test fixture for testing artifact selectors in GMM

  1. … 9 more files in changeset.
Adjust test fixtures and test to ivy behavior changes

  1. … 37 more files in changeset.
Remove special casing of pure ivy in resolve tests

  1. … 9 more files in changeset.
Remove special casing of pure ivy in resolve tests

  1. … 10 more files in changeset.
Use ivy derivation rules in resolve tests

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

  1. … 12 more files in changeset.
Use ivy derivation rules in resolve tests

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

  1. … 12 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

  1. … 15 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

  1. … 20 more files in changeset.