CapabilitiesRulesIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Register implicit capabilities for conflict detection in more cases (#11334)

In general conflict detection for implicit capabilities is skipped

for performance optimization. However, if the corresponding capability

is explicitly declared by another component that was visited *before*,

we need to do the conflict detection between the component with

the implicit capability and the one visited earlier.

See also: #11300

    • -0
    • +59
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 4 more files in changeset.
Register implicit capabilities for conflict detection in more cases (#11334)

In general conflict detection for implicit capabilities is skipped

for performance optimization. However, if the corresponding capability

is explicitly declared by another component that was visited *before*,

we need to do the conflict detection between the component with

the implicit capability and the one visited earlier.

See also: #11300

    • -0
    • +59
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 4 more files in changeset.
Add test case to reproduce #11300

    • -0
    • +59
    ./CapabilitiesRulesIntegrationTest.groovy
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

    • -5
    • +5
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 66 more files in changeset.
Revert "Merge branch 'release'"

This reverts commit c7fdc455dcb9a8016af0ae9bc8b4c43fde1e2d06, reversing

changes made to 9f70d52b74dbc8c71381781b6c155474031b3cf8.

The changes need a wrapper as there are API changes. Reverting for now.

    • -5
    • +5
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 66 more files in changeset.
Support variant selection in capability conflict resolution (#10973)

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

    • -5
    • +5
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 13 more files in changeset.
Support variant selection in capability conflict resolution

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

    • -5
    • +5
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 13 more files in changeset.
Support variant selection in capability conflict resolution

A conflict can also occur between two variants of the same component.

This gives access to the variant name in the selection rule and

evicts nodes that represent the not-selected variant.

    • -5
    • +5
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 12 more files in changeset.
Adjust test fixtures and test to ivy behavior changes

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 38 more files in changeset.
Remove special casing of pure ivy in resolve tests

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 9 more files in changeset.
Remove special casing of pure ivy in resolve tests

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 11 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.

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  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.

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 12 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 15 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 18 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 20 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -6
    • +2
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 20 more files in changeset.
Adjust tests and samples to new metadata sources defaults

    • -1
    • +1
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 95 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -1
    • +1
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -1
    • +1
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -1
    • +1
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 32 more files in changeset.
Split method for readability and fix indent

    • -3
    • +3
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 1 more file in changeset.
Add customizable capability conflict resolution

This commit disables the automatic capability conflict

resolution based on the highest version of a capability

and replaces it with a customizable resolution strategy.

This allows better control on how capability conflicts

are handled: before this change, capabilities could be

automatically upgraded just because they had a higher

version, which is not always acceptable.

The new API gives finer control by providing a DSL on

the resolution strategy which allows:

- explicitly setting "highest wins" strategy for a given

capability

- or choosing explicitly between a list of modules in conflict

for a given capability

It is possible to use a generic _all_ call to configure the

strategy independently of the capability.

Closes #9888

    • -2
    • +15
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 19 more files in changeset.
Add customizable capability conflict resolution

This commit disables the automatic capability conflict

resolution based on the highest version of a capability

and replaces it with a customizable resolution strategy.

This allows better control on how capability conflicts

are handled: before this change, capabilities could be

automatically upgraded just because they had a higher

version, which is not always acceptable.

The new API gives finer control by providing a DSL on

the resolution strategy which allows:

- explicitly setting "highest wins" strategy for a given

capability

- or choosing explicitly between a list of modules in conflict

for a given capability

It is possible to use a generic _all_ call to configure the

strategy independently of the capability.

Closes #9888

    • -2
    • +15
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 19 more files in changeset.
Add customizable capability conflict resolution

This commit disables the automatic capability conflict

resolution based on the highest version of a capability

and replaces it with a customizable resolution strategy.

This allows better control on how capability conflicts

are handled: before this change, capabilities could be

automatically upgraded just because they had a higher

version, which is not always acceptable.

The new API gives finer control by providing a DSL on

the resolution strategy which allows:

- explicitly setting "highest wins" strategy for a given

capability

- or choosing explicitly between a list of modules in conflict

for a given capability

It is possible to use a generic _all_ call to configure the

strategy independently of the capability.

Closes #9888

    • -2
    • +15
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 19 more files in changeset.
Make capabilities conflict error lenient

When a capability conflict cannot be resolved, it is now recorded on the

graph, similarly to a version conflict. It means that the error becomes

lenient, allowing consumption of the result in a lenient fashion.

It also enables analyzing capabilities conflict through

`dependencyInsight` amongst other.

Fixes #8428

    • -2
    • +10
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 16 more files in changeset.
Consistently report conflict resolution

This commit refactors how conflict resolution selection reasons are handled, in order to:

- collect the list of versions which participated in conflict resolution

- report a single conflict resolution cause when conflicts are resolved several times for the same module

- consistently report module replacement rules as rules, not conflict resolution. Before this change,

a module replacement was reported as both a conflict and a rule

    • -1
    • +1
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 29 more files in changeset.
Migrate test to ComponentMetadataRule usage

This covers a number of tests that were missed on the previous pass.

    • -27
    • +53
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 7 more files in changeset.
Fix NPE in capabilities conflict resolution

It is possible that a large dependency graph resolves capabilities conflicts 2 by 2, at

different "depth" in the transitive graph. In this case, it is possible for a module to

be selected, but then it needs to be considered again when a new module providing the

same capability appears in the graph. If not, we wouldn't choose any version, producing

an NPE when we read the graph back from the binary store.

The error was discovered during dogfooding, so this commit is a pre-requisite to using

capabilities in the Gradle build (will require a wrapper update).

This commit also improves the selection reason in case of capability conflict resolution,

to make it clear it was upgraded to the latest version.

    • -1
    • +1
    ./CapabilitiesRulesIntegrationTest.groovy
  1. … 4 more files in changeset.
Add missing test coverage for removal of capabilities

There wasn't any test coverage for rules which remove capabilities.

    • -0
    • +55
    ./CapabilitiesRulesIntegrationTest.groovy