ResolveTestFixture.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Differentiate between dependency and constraint edges in `ResolveTestFixture`

  1. … 8 more files in changeset.
Simplify verification of constraints in `ResolveTestFixture`

  1. … 3 more files in changeset.
Track unmatched versions in SelectorState

Previously, when resolving a selector we were registering the unmatched

versions at the component level. The `ComponentState` would keep a map

of selector -> unmatched versions, which would later be reconnected to

the original selector.

With this change, the unmatched versions are kept with the `SelectorState`

until required to form a component selection reason. This simplifies the

logic and reduces the number of collection copies required.

  1. … 11 more files in changeset.
Implement variant derivation strategy

This commit changes how Maven metadata is derived into variants. Now we will

only derive variants if the Java plugin is applied (the "base Java" plugin).

This is implemented via a variant derivation strategy, and allows fixing

the problem that a native component is unlikely to find sense in the derivation

of Java variants. This fixes a bug where the native plugins wouldn't be able

to consume native libraries published on Maven repositories, without Gradle

metadata.

  1. … 43 more files in changeset.
Add support for forcing a platform using a constraint

This commit adds support for aligning a platform to a forced

version using a constraint. Similarly to the dependency case,

this allows forcing the platform, but also implies that the

members of the platform are _also_ forced.

  1. … 6 more files in changeset.
Update Nebula recommender plugin version for smoke test

The ResolveTestFixture needed a fix to handle selection reasons with a

newline character.

The test assertions have changed as 'selected by rule' now requires

additional message.

Fixes #6177

  1. … 2 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. … 29 more files in changeset.
Collect unmatched dependencies too

Without this change, it is not possible to know which versions Gradle

considered for a dynamic range, unless it's rejected by a rule or by

attribute matching.

  1. … 19 more files in changeset.
Collect unmatched dependencies too

Without this change, it is not possible to know which versions Gradle

considered for a dynamic range, unless it's rejected by a rule or by

attribute matching.

  1. … 19 more files in changeset.
Use register() over createLater() in all built-in plugins

  1. … 9 more files in changeset.
Associate rejected versions with their constraint or rule

This commit reworks the mapping between rejected versions and

version selectors, so that we can make the difference between

a version which was rejected by a selector (regular or constraint)

or a rule. Then the dependency insight report can properly show

what versions were rejected in which context.

  1. … 18 more files in changeset.
Associate rejected versions with their constraint or rule

This commit reworks the mapping between rejected versions and

version selectors, so that we can make the difference between

a version which was rejected by a selector (regular or constraint)

or a rule. Then the dependency insight report can properly show

what versions were rejected in which context.

  1. … 18 more files in changeset.
Bridge tasks into software mode lazily

Only initialize the software model bridging if the user

either uses the `model {}` block or explicitly applies

a rule-based plugin.

Placeholder tasks are now implemented in the task container

directly instead of using the software model. They are also

deprecated as they add a lot of complexity for no gain beyond

what `createLater {}` already offers.

  1. … 29 more files in changeset.
Honor constraint attribute during selection

This commit makes sure that attributes from all selectors are used during

selection, including the attributes from constraints. It does not, however,

make sure that those attributes are consistent (compatible).

  1. … 13 more files in changeset.
Use dependency attributes when selecting variants of a single component

This commit makes sure that attributes defined on a dependency are used whenever

a component has multiple variants, and we need to select one of the variants.

However, this doesn't work yet when an attribute on a dependency overrides the

consumer attributes (the attributes defined on a configuration). In this case,

we will rightfully select the variant, but as soon as we try to get the artifacts

of this variant, we will fail, because we're selecting _again_ the variant, but

the only thing we have at this point is the selected component and the consumer

attributes (we have lost the dependency attributes).

  1. … 10 more files in changeset.
Separate Dependency Constraint and Dependency declarations (#4255)

The interfaces for declaring these two different things were

coupled in the initial implementation - to reuse all functionality

based on the Dependency interface directly. This interface is used

internally to pass dependency declarations through the resolution

process. However, this is only due to remembering the first

level dependencies for the "old" results API

(Configuration.resolvedConfiguration()).

These implementation specifics should not bleed into the API.

A dependency declaration defines a *requirement*:

I require module/project X

A dependency constraint defines a *constraint*:

If I must use X, I can only work with versions matching the constraint

Only if we look at external dependencies, constraints and external dependencies

share the ability to declare a *version constraint*. Therefore, both now

extend ModuleVersionSelector.

Now, dependency constraints are removed as "first level dependencies"

from the result. This is fine as the dependency itself is still in the

result graph - when there is a constraint, there is always at least one other

edge.

  1. … 33 more files in changeset.
Fix ResolveTestFixture so that it correctly reports missing nodes

Test timestamped identifier for resolved snapshots

  1. … 4 more files in changeset.
Improve `ResolveTestFixture` to support multiple reasons

The resolve test fixture only took the last "description" into consideration. This makes it hard to write tests for custom dependency

reasons. Also, the output of the comparison wasn't very developer friendly, because it was showing the internal, stringy, representation

of the dependency graph nodes.

This commit improves everything by not relying on string comparisons anymore to compare the components. Edges are still compared using

strings, but it already makes things much easier to reason about.

Rework component selection reason to support composite explanations

This commit changes how `ComponentSelectionReason` works, so that we can save a list of selection

reasons, instead of a single one. This should let us give richer explananations about why a component

was selected. In particular, a component may be selected because another one was rejected, or it

can be selected by a rule **and** by conflict resolution. This last case was handled in an adhoc

manner, it's now a regular case.

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

  1. … 41 more files in changeset.
Remove `ResolvedNamedVariantResult`

This commit removes the "named" version of the resolved variant resolution result

in favor of a `getDisplayName()` method directly on `ResolvedVariantResult`.

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

  1. … 10 more files in changeset.
Update test to show the resolved result gives access to the target variant attributes

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

  1. … 2 more files in changeset.
Add support for showing the resolved variant and its attributes in `ResolvedComponentResult`

This commit adds a `ResolvedNamedVariantResult getVariant()` method on `ResolvedComponentResult`,

which gives access to the resolved variant details. In practice, the details are currently limited

to:

- the name of the variant

- the attributes attached to this variant

The attributes are desugared: if the original variant had strongly-typed attributes, what we get

by the result of this call is an attribute container where all attributes are of type `String`.

As a consequence, it should only be used for diagnostics.

The `ResolveTestFixture` has been adjusted so that we can now (optionally) check the selected

variant and its attributes. One test has been adjusted to check the variant.

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

  1. … 25 more files in changeset.
Add test to show that custom reason for dependency substitution is available in resolution result

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

  1. … 1 more file in changeset.
Let Maven and Ivy module fixture provide java library variants

  1. … 8 more files in changeset.
Rename 'isCompositeParticipant' to 'isCompositeSubstitution'

  1. … 2 more files in changeset.
Tweak ComponentSelectionReason interface

- rename isCompositeBuild -> isCompositeParticipant;

- tweak javadoc

Signed-off-by: Rene Groeschke <rene@gradle.com>

  1. … 2 more files in changeset.
Expose composite build explicitly as ComponentSelectionReason

* to have stronger api to detect composite build as selection reason

just relying on the description method is not strong enough.

* This change adds ComponentSelectionReason#isCompositeBuild() that can

be checked by consumers (e.g. Build Scan plugin) to detect this scenario

Signed-off-by: Rene Groeschke <rene@gradle.com>

  1. … 2 more files in changeset.
Improve assertions in bom support smoke test

  1. … 1 more file in changeset.
Add smoke test for bom support

The test resolves dependencies for a spring boot project by using

the spring boot dependencies BOM. There are three variants of the

test using different mechanisms for BOM support:

- Built-in support from Gradle

- Nebula Recommender Plugin

- Spring Dependency Management Plugin

    • -0
    • +634
    ./ResolveTestFixture.groovy
  1. … 2 more files in changeset.