AbstractConfigurationAttributesResolveIntegrationTest.groovy

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove Jar task related duplication in integration tests

    • -211
    • +34
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 2 more files in changeset.
Make AbstractArchiveTask.destinationDir mandatory

Prior to this commit the working directory was used when the

`destinationDir` was not set. Since this behavior does not play nice

with reproducible builds, it will now fail instead. However, it should

rarely happen because the `base` plugin provides a convention.

    • -0
    • +30
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 26 more files in changeset.
Make AbstractArchiveTask.destinationDir mandatory

Prior to this commit the working directory was used when the

`destinationDir` was not set. Since this behavior does not play nice

with reproducible builds, it will now fail instead. However, it should

rarely happen because the `base` plugin provides a convention.

    • -0
    • +30
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 26 more files in changeset.
Consistently use component level attributes

Component-level attributes were only used if the component metadata was using Gradle

metadata. This was particularly confusing, as it was possible to define a component-

level attribute in a component-metadata rule, but it would be ignored during matching.

It was possible, however, to add attributes on variants of Ivy or Maven metadata,

but then the error messages in case there wasn't any match was even more confusing:

"Because there are no configurations with attributes"

This commit modifies the resolution engine so that it's possible to use component

level attributes independently of whether the underlying component metadata was

constructed from Ivy, Maven or Gradle metadata. It also changes the error messages

to mention either "configuration" or "variant" depending on whether the matching

strategy was using variant-aware dependency management *or* legacy configurations.

It was confusing because we have the `IMPROVED_POM_SUPPORT` flag which activates

variant construction from Maven metadata. This meant that in practice, if the flag

was active, we were using variants, but still the component level attributes were

not taken into account. If the flag wasn't active, then we would fail with the

error above, despite the fact we had rules on "configuration backed variants".

The separation of configuration/variant in error messages makes it easier for

us to understand in which case we are, since this wasn't always obvious. If we

see "variant", then now we know that the selection failed using the variant-aware

matching. If we see "configuration", then we know it's using the legacy mode.

This commit also needed to make the difference between "this component has no

variant" and "this component doesn't provide any mapping to variants", therefore

the introduction of the `Optional` on `getVariantsForTraversal`. This gives us

the opportunity to give the correct error message in case of failure using

the legacy mode.

Last but not least, this introduces a change in the attributes visible on variants

**and** artifacts. Before this commit, dependending on whether metadata was

Gradle metadata, the "status" attribute would be found or not. Now, the component

level attributes are _always_ merged to variant and artifact attributes, which

means that it's consistent independently of the format. This can be a breaking

change, but a low risk one.

    • -30
    • +39
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 39 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>

    • -5
    • +31
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 2 more files in changeset.
On CI redirect jcenter queries to local repo for integration tests

    • -2
    • +2
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 51 more files in changeset.
Remove `assumeCompatibleWhenMissing` from `CompatibilityRuleChain`

This method was already a no-op. Now is time for removal.

    • -53
    • +29
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 10 more files in changeset.
Changed the way that the target configuration for a project dependency is calculated, to always select only from the configurations of the target project that have attributes attached, regardless of whether the consumer has defined any attributes or not. Fall back to `default` only when the target project has no configurations with attributes defined.

This introduces a breaking change when consuming the output of a project with the Java plugin applied from a project that does not have the Java plugin applied. Previously, the `default` configuration would be selected, now the `runtimeElements` configuration is selected. However, this is consistent with the case where the consuming project is also using the Java plugin or is using the Android plugin. It also means that custom configurations in these projects will select the same thing as the runtime classpath configuration.

    • -1
    • +57
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 13 more files in changeset.
Treat various kinds of dependency resolution failures in more consistent ways.

- When a non-lenient view is used as a task input, then propagate any failure to select a configuration in the dependency graph during task graph calculation, rather than suppressing these kinds of failures and propagating later when the files happen to be queried. This now happens consistently whether fluid dependencies are used or not. The only difference between these is how much of the graph is traversed at task graph calculation time.

- When a lenient view is used as a task input, suppress configuration selection failures during task graph calculation and instead present them in `ArtifactCollection.failures`. Do this consistently regardless of whether fluid dependencies are used or not. Previously this kind of failure was propagated during task graph calculation for lenient views.

Also changed the error message on resolution failure to include what kind of query was being performed at the time to trigger the failure.

From an implementation point of view, separated the handling of selection failures from the code that produces the legacy resolution result so that this handling can be reused when the legacy result is not required (such as, say, when calculating the task graph).

    • -6
    • +2
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 34 more files in changeset.
Do not treat a failure to select the target configurations for a particular dependency edge as a fatal error, and instead treat this kind of failure in the same way as other kinds of failures and continue with dependency graph resolution.

    • -3
    • +8
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 3 more files in changeset.
Changed configuration selection during dependency resolution so that when the consumer defines some attributes the matching falls back to the `default` configuration only when the target component has no configurations with attributes attached. Otherwise, the `default` configuration is treated the same way as all other configurations and treated as a candidate only when it has attributes attached.

Previously, the `default` configuration was used when there were no _matching_ configurations with attributes attached in the target component.

The behaviour is unchanged when the consumer or target component do not define any attributes or the `default` configuration is explicitly selected.

    • -14
    • +12
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 7 more files in changeset.
Improved the 'no matching variant' and 'too many matching variant' error messages to use a better description of each of the variants, such as which project/module and configuration the variant belongs to.

Made a bunch of changes to forward the display name of the variant from where the variant originates from through to the variant selection logic so it can construct the error messages, using `Describable` to represent the display name.

    • -8
    • +8
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 34 more files in changeset.
Fail when no compatible variant can be selected for a component. Continue to ignore components with no compatible variant when using an `ArtifactView` with additional attributes defined, whose implicit contract is to ignore these (this should be an explicit contract).

Made some changes to error messages so that failure to select a variant shows the same useful details as a failure to select a configuration.

    • -53
    • +17
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 24 more files in changeset.
Changed attribute matching to chain the producer's rules after the consumer's rules, rather than stopping at the end of the consumer's rules. This allows the consumer to reuse the producer's rules but override certain decisions, and it allows the producer to add new values for an attribute that the consumer knows about which are compatible with the consumer value.

    • -14
    • +12
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 23 more files in changeset.
Consider the attributes attached to the configuration when selecting a variant.

    • -78
    • +257
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 6 more files in changeset.
Some improvements to the 'found multiple transforms' error message. Also apply some consistent formatting to some of the other variant error messages, by reusing `TreeFormatter`.

    • -45
    • +48
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 11 more files in changeset.
Unify attribute modification API

Unified API for through shared interface (HasConfigurableAttributes):

- Configuration

- ConfigurationVariant

- ArtifactView

This removes convenience methods from all three interfaces in

favor of a unified API that uses strongly typed attributes.

    • -90
    • +90
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 29 more files in changeset.
Move `configurationAttributesSchema` down to `DependencyHandler`

This commit fixes gradle/performance#251 by moving the attributes schema to the dependency handler. It's worth noting that

is also renames the configuration method from `configurationAttributesSchema` to simply `attributesSchema`.

    • -48
    • +60
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 18 more files in changeset.
Ignore extra attributes when selecting a variant for a dependency graph node, pending a less lenient and more accurate implementation.

    • -3
    • +7
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 1 more file in changeset.
Improve error message in case we fallback to the `default` configuration but it's not consumable

Since we call fallback on the `default` configuration in case no matching configuration is found with the

consumer attributes, it is possible that this configuration is not consumable, in which case dependency

resolution should fail. This was the case but the error message was unclear, as it was somehow telling

the user that they had selected `default` explicitly. Instead, the error message now lists the configurations

which failed to match, with their respective attributes.

    • -1
    • +107
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 5 more files in changeset.
Revalidate that selected configurations match the requested attributes

This commit changes the behavior of dependency resolution in case a selected configuration doesn't match

the requested attributes. It could happen in two cases:

- in case no matching configuration is found, we fallback to the `default` configuration, which could have attributes

that did *not* match (it was part of the selection, but in the end since no configuration was matching, it was selected

anyway).

- in case an explicit configuration was chosen. In that case, we didn't check that the selected configuration matched

the consumer attributes.

Error messages have been improved as part of this story. It's worth noting that this commit does NOT change the

selection algorithm, and we will always fallback to the `default` configuration in case no match is found. The only

thing it does is really revalidating that this fallback is compatible.

See gradle/performance#233

    • -1
    • +66
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 5 more files in changeset.
Improve error messages in case of ambiguous matches

This commit adds the target component name in the error message, making it clearer where the problem is.

    • -6
    • +6
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 5 more files in changeset.
Merge `optionalOnConsumer` and `optionalOnProducer`

This commit merges the implementations of `optionalOnConsumer` and `optionalOnProducer`

rules into a single `assumeCompatibleWhenMissing()` call. Note that the semantics of

"missing" here are slightly different from the semantics of missing on `AttributeValue`

because it will apply equally to both unknown and missing attributes.

    • -14
    • +13
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 7 more files in changeset.
Rename `configureMatchingStrategy` to `attribute` and add a no configure action variant

    • -13
    • +13
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 15 more files in changeset.
Remove the need for special handling of partial matches

Partial matches are no longer a special case with this commit. Instead, the

strategy defines what to do in case an attribute is missing or unknown, in

both the consumer and producer side. This allows richer matching strategies,

where an attribute can become optional, instead of being systematically

optional.

This changes the default strategy, by requiring an explicit call to

`optionalOnXXX` to make an attribute missing relevant or not.

    • -3
    • +67
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 17 more files in changeset.
Make sure we don't fallback on the `default` configuration if it's not consumable

Before this commit, if we didn't find any match, we unconditionnaly felt back to the `default`

configuration, even if it wasn't consumable. Now, selection will honor the `canBeConsumed`

flag in both cases: explicit configuration selection *and* fallback.

    • -0
    • +50
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 4 more files in changeset.
Fix partial matching of attributes

There was a problem in the algorithm when a configuration was partially matching,

but one of its attributes wasn't compatible. Then it was considered a partial match

but it shouldn't have.

    • -0
    • +57
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 2 more files in changeset.
New attempt to fix tests on Windows

    • -14
    • +23
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 1 more file in changeset.
Fix tests on Windows

    • -6
    • +8
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 1 more file in changeset.
Improved error messages in case of ambiguous matchs

This commit provides a better error message in the case we cannot choose between multiple configurations.

It will display an error message that gives the expected values, the missing attributes, and the attributes

that were found but not requested.

    • -11
    • +51
    ./AbstractConfigurationAttributesResolveIntegrationTest.groovy
  1. … 2 more files in changeset.