Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add support for 'forSubgraph' to metadata test fixtures

    • -1
    • +2
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 7 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

    • -1
    • +2
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 7 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

    • -1
    • +2
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 7 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

    • -1
    • +2
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 7 more files in changeset.
Add support for 'forSubgraph' to metadata test fixtures

    • -1
    • +2
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 7 more files in changeset.
Add selector override functionality to resolution engine

    • -1
    • +2
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 11 more files in changeset.
Add selector override functionality to resolution engine

    • -1
    • +2
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 8 more files in changeset.
Add selector override functionality to resolution engine

    • -1
    • +2
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 8 more files in changeset.
Fail resolution if 2 variants provide the same capability

This commit makes sure that we fail resolution whenever two variants

of a component provide the same capability. However, it doesn't do so

for the implicit variant yet.

    • -1
    • +20
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 19 more files in changeset.
Fix undeterministic order of resolution of capability conflicts

Previous to this commit, it was possible to resolve conflicts between

modules providing the same capability in a random order. Now the order

is consistent, making it sure that the result of resolution is always

the same.

Fixes #5920

    • -0
    • +103
    ./DefaultCapabilitiesConflictHandlerTest.groovy
  1. … 1 more file in changeset.
Rename `registerModule` to `registerCandidate`

  1. … 4 more files in changeset.
Consume capabilities from external modules

This commit introduces the ability to consume capabilities from external

modules. This is a pretty big change for multiple reasons:

- capabilities are no longer known beforehand (before resolution starts) but

can be discovered as we add more nodes to the graph

- conflict resolution cannot fail fast anymore, since it is possible for a

module to declare a capability that triggers a conflict with another module

in the graph, but a 3rd party module can express a preference

- capabilities are consumed from Gradle metadata files

- capabilities from the local component and capabilities from the graph are

merged during resolution

Capabilities are, in published metadata, available at the component level,

with the assumption that capabilities are the same for all variants. It is

not necessary for a module to express a preference for a capability, as

a 3rd party module can declare only a preference, for example.

  1. … 49 more files in changeset.
Wire capabilities handling into conflict resolution

Handling of capabilities is now delegated to the conflict handler, which allows different things:

1. if two modules provide the same capability, but no preference is set, conflict resolution fails

2. there's no need to convert the capabilities to replacement rules anymore

It's worth noting that this currently only works if a single capability is conflicting. Behavior

when there are more than one capability for conflicting modules is undefined at this point (will

be fixed later)

  1. … 18 more files in changeset.
Support custom selection reasons for module replacements

This commit adds the ability to use a custom selection reason when a module is replaced with

another.

Signed-off-by: Cedric Champeau <cedric@gradle.com>

  1. … 7 more files in changeset.
Make sure we don't create conflicts when the candidate list is empty

It is possible that we're out of candidates now that we filter out versions which are not

selectable from candidates. This happens when we have an orphan node, then a selector chooses

the same version, but cannot be used for short-circuiting (typically, `latest` selector).

  1. … 3 more files in changeset.
Introduce a way to restart selection of a module

This commit allows restarting selection of a module from a conflict resolution rule. The idea is to be able to restart

selection when "new information" is available. One use case is the range selection of a module. If, during graph

visit, a different range is seen, then we know we can potentially have disjoint ranges, in which case classic

resolution occurs, or intersecting ranges, in which case we need to select the highest version in range. This commit

prepares a different solution to the problem by allowing us to restart selection once we determine we have two

intersecting ranges.

It's worth noting that this commit requires temporary disabling of the tests, because the rule doesn't enforce this

behavior: it will now create an infinite loop, without ever selecting a version. The reason is precisely that we

don't make this "new information" available to selection. This will be implemented in a subsequent commit.

    • -125
    • +0
    ./MultipleCandidateModulesConflictResolverTest.groovy
  1. … 5 more files in changeset.
Update `ModuleConflictResolver` to use the details pattern

Instead of having a single `select` method which returns the selected candidate, the method is now void, but uses

a `ConflictResolverDetails` parameter, that a conflict resolver can use to select a candidate. This enables cleaner

separation from error cases (in which case we need to call the `fail` method), from actual selection (the `select`

method). It also makes it possible to clearly separate cases where a resolver had _no opinion_ from the case where

it doesn't actually perform a selection.

This work is preliminary work to enabling resolvers that will not _choose_ a version, but instead restart part of

the resolution process based on new information.

    • -2
    • +10
    ./DefaultConflictHandlerTest.groovy
    • -10
    • +16
    ./MultipleCandidateModulesConflictResolverTest.groovy
  1. … 13 more files in changeset.
Add test coverage for version range conflict resolution

    • -0
    • +119
    ./MultipleCandidateModulesConflictResolverTest.groovy
  1. … 1 more file in changeset.
Renamed a class.

  1. … 15 more files in changeset.
Component replacements: added new feature. Now it is possible to replace multiple modules with the same replacement target. I haven't created any new DSL for this because it is not needed - one can declare this case using the current DSL (we could add something better for this later if needed).

  1. … 2 more files in changeset.
Renamed subprojects/core-impl to subprojects/dependency-management.

    • -0
    • +129
    ./ConflictContainerTest.groovy
    • -0
    • +101
    ./DefaultConflictHandlerTest.groovy
  1. … 1383 more files in changeset.