CapabilitiesUseCasesIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Change `AbstractIntegrationSpec` to fail when a test runs a build that fails with more than one exception and does not verify the number of exceptions in the failure using `assertHasFailures()`.

This is to avoid additional exceptions unintentionally being introduced, for example when a failure starts being thrown because of configuration cache problems alongside the expected failure.

    • -0
    • +6
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 81 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>

    • -16
    • +11
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 43 more files in changeset.
Adjust tests and samples to new metadata sources defaults

    • -3
    • +3
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 95 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

    • -0
    • +1
    ./CapabilitiesUseCasesIntegrationTest.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

    • -4
    • +30
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 16 more files in changeset.
Update handling of capabilities conflict

Previously these conflicts were not handled when `failOnVersionConflict`

was enabled. Instead they would fail directly.

Now we always try to resolve capabilities conflict and simply rely on

the fail on version conflict visitor to detect such conflicts and report

on them.

Issue #8428

    • -1
    • +1
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 1 more file in changeset.
Initial support for optional features

This commit introduces initial support for optional features, by

implementing a way for a dependency declaration (currently *only* in

the DSL) to request variants of the target component that provide one

or more capabilities.

Previously to this change, selection was (simplified) done like this:

1. find the target component

2. select the variant of the target component which matches the requested

attributes

Now, selection introduces another step:

1. find the target component

2. filter variants by eliminating those which do not provide the requested

capabilities

3. select the variant in this list which matches the requested attributes

Several changes had to be implemented:

First, component metadata rules calling `addCapability` will now return

a component which capabilities _include_ the default capability.

Second, attribute filtering is done in a secondary step, which means that

if there are no variant matching the requested capabilities, we will immediately

fail.

    • -0
    • +3
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 58 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

    • -3
    • +3
    ./CapabilitiesUseCasesIntegrationTest.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.

    • -23
    • +44
    ./CapabilitiesUseCasesIntegrationTest.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
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 4 more files in changeset.
Make it possible to fail on capability version conflict

If the configuration resolution strategy is set to fail on version conflict,

then capabilities will not automatically be upgraded to the latest version.

Instead, just like regular conflict resolution, dependendency resolution will

fail with an error listing the capability with the conflicting versions.

    • -12
    • +31
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 3 more files in changeset.
Add an implicit capability for each component

This commit makes sure that every component has an implicit capability corresponding

to its GAV coordinates. For example, the module `asm:asm:3.0` has an implicit capability

with the same group, name and version. This simplifies rules, in particular when a module

needs to explain that it provides the same capability as a different module published

at different coordinates.

    • -41
    • +2
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 3 more files in changeset.
Make sure tests prove something by not systematically apply fix

This commit splits the test cases for fixing capability conflicts in two variants:

- one which only applies the component metadata rules to create a conflict, but without fixing

- one that additionally applies a fix, as the user would have to write

    • -71
    • +149
    ./CapabilitiesUseCasesIntegrationTest.groovy
Add test cases documenting some use cases for capabilities

This commit just introduces more test coverage, aimed at showing typical use cases

for capabilities, and how to resolve conflicts using traditional means (aka, dependency

substitution).

It's worth noting that usage of dependency substitutions force us to select a target

version for the module.

    • -0
    • +415
    ./CapabilitiesUseCasesIntegrationTest.groovy
  1. … 1 more file in changeset.