ResolvedArtifactsApiIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Reshuffle some tests into subpackages

This is just a refactoring of tests, to make it clearer: the base

package started to grow significantly.

    • -970
    • +0
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 79 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.

    • -1
    • +8
    ./ResolvedArtifactsApiIntegrationTest.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.

    • -1
    • +8
    ./ResolvedArtifactsApiIntegrationTest.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.

    • -4
    • +4
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 39 more files in changeset.
Limit the type of attributes to types we can make immutable

This commit restricts the possibilities of custom types for attributes. Since attributes are used in various

places, potentially different classloaders or even different process, we need a stable way to make them

both snapshottable and serializable. This commit is the first step, by making it impossible to create attributes

with arbitrary types.

Types that we support include:

- scalar types, which are primitive types (and their wrappers), `File` or `String` (aka, known immutables)

- a type extending `Named`, in which case it is expected to create values using the `ObjectFactory`

- an enum

- an array of the above (arrays are not immutable, but we can create immutable values out of arrays)

Some tests had to be adjusted, because they didn't match those constraints. Future work will include possibilities

to include richer types.

    • -1
    • +1
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 5 more files in changeset.
Remove `assumeCompatibleWhenMissing` from `CompatibilityRuleChain`

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

    • -3
    • +3
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 10 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).

    • -2
    • +64
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 34 more files in changeset.
Include each of the dependency graph resolution failures in `ArtifactCollection.failures` when in lenient mode, rather than grouping them together as causes of a single `ResolveException`.

For artifact/file query methods that are not lenient, fail eagerly when the dependency graph cannot be fully resolved, rather than continuing and attempting to resolve the artifacts. This was the previous behaviour of these methods.

Also removed a duplicate from the exception chain when these methods do fail due to a dependency graph problem.

    • -32
    • +27
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 11 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.

    • -51
    • +51
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 3 more files in changeset.
Attempt to resolve an artifact only once per configuration (including all views of the configuration). If the resolution fails, collect the failure and rethrow when queried again later.

    • -3
    • +1
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 4 more files in changeset.
Reworked the collection of file dependencies during dependency graph traversal, so that the files from these dependencies are ordered the same way as other kinds of dependencies, rather than always ordering these files at the start of the result.

    • -11
    • +11
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 16 more files in changeset.
Some improvements to the formatting of 'no matching variant' and 'too many matching variant' error messages.

Also replaced some usages of `Factory<String>` with `Describable` to represent the display name of various child objects of `Configuration`.

    • -4
    • +4
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 37 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.

    • -4
    • +4
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 34 more files in changeset.
Added some constraints on the 'from' and 'to' attributes for a consumer provided variant, to help the user avoid attempting various cases that are not yet really supported.

- The 'to' and 'from' attributes must be not empty. Empty 'from' basically means "I can transform _any_ input" and an empty 'to' basically means "I can produce _any_ output (without knowing what it is)", neither of which make much sense.

- The 'to' attributes must be a subset of the 'from' attributes. Adding attributes to make a more specific variant is not required yet, and will break when switching 'compatible when missing' to default to true. For now, disable this case.

    • -0
    • +1
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 7 more files in changeset.
Don't treat a failure to select a producer variant as a fatal failure, and instead treat it the same way as other artifact resolution failures, by collecting the failure and continuing.

This change means that these failures appear in the result returned by `ArtifactCollection.getFailures()` for a lenient collection.

    • -3
    • +34
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 7 more files in changeset.
Include the component display name in the various error messages when unable to select a variant of the component (such as multiple matches, no matches, etc), to help with diagnostics.

    • -1
    • +1
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 15 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.

    • -10
    • +9
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 24 more files in changeset.
Added more test coverage for variant selection through various APIs.

    • -0
    • +297
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 2 more files in changeset.
Don't ignore the producer's attributes when selecting a variant.

    • -9
    • +7
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 4 more files in changeset.
Another attempt to fix test on windows

    • -4
    • +4
    ./ResolvedArtifactsApiIntegrationTest.groovy
Fix test on windows

    • -6
    • +11
    ./ResolvedArtifactsApiIntegrationTest.groovy
Collect failures in lenient `ArtifactCollection`

    • -26
    • +85
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 3 more files in changeset.
Use a single action to configure an `ArtifactView`

gradle/performance#487

    • -29
    • +31
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 16 more files in changeset.
Add `lenient` option to `artifactView()`

By choosing a lenient view, the returned `FileCollection` or `ArtifactCollection`

will return any resolved files/artifacts, ignoring failures.

    • -0
    • +41
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 10 more files in changeset.
Fail artifact resolution when an artifact transform produces an output that is not one of its inputs or a child of its output directory.

    • -2
    • +1
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 5 more files in changeset.
Do not provide target attributes to `ArtifactTransform.transform()`

An `ArtifactTransform` instance is now a simple File->List<File> transformer.

The target attributes are not a direct input into the transform function.

This will allow us to be more efficient in our caching of transform outputs.

To provide target-specific transformation behaviour, the transform instance

for a particular target should be configured with the necessary target

information.

gradle/performance#212

    • -3
    • +3
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 8 more files in changeset.
Don't permit arbitrary configuration of `ArtifactTransform` instances

Previously, an arbitrary closure could be used to configure any user-defined

`ArtifactTransform` instances. This mechanism makes it difficult to isolate

the transform process from the calling process, and prevents optimizations

like parallelization, caching, etc.

Instead, a user can now provide a set of parameters that are provided to the

instance via constructor injection. Any object is currently supported, with

a plan to restrict this to `Serializable` parameters in the future.

gradle/performance#212

    • -1
    • +1
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 15 more files in changeset.
Split registration from configuration for ArtifactTransform

This change splits the function that performs an artifact transform from

the configuration of what variants are transformed to what other variants.

The `from` and `to` attributes are registered directly when registering

a transform, which can be re-used for different attribute mappings.

gradle/performance#212

    • -0
    • +72
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 18 more files in changeset.
Shuffled around some test coverage.

    • -84
    • +53
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 2 more files in changeset.
Don't include extension or classifier as variant attributes.

    • -4
    • +2
    ./ResolvedArtifactsApiIntegrationTest.groovy
  1. … 2 more files in changeset.