DefaultArtifactTypeRegistryTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add support for adding variants and files to component metadata rules

    • -5
    • +6
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 32 more files in changeset.
Add support for adding variants and files to component metadata rules

    • -5
    • +6
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 32 more files in changeset.
Add support for adding variants and files to component metadata rules

    • -5
    • +6
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 29 more files in changeset.
Add test coverage for mapping arbitrary files

    • -0
    • +70
    ./DefaultArtifactTypeRegistryTest.groovy
Allow the services required by a given class to be queried prior to creating any instances of that class. Use this to allow `ArtifactTransformDependencies` to be injected into artifact transforms using any of the service injection patterns (that is, via a constructor or a getter).

    • -1
    • +1
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 127 more files in changeset.
Replace most direct usages of `DirectInstantiator` with indirect usages via `InstantiatorFactory` or test fixtures instead. This means more consistent behaviour in unit tests because the objects under test will behave more similarly to how they do at runtime. This also allows the decision of how the instantiation should behave to live in as few places as possible, so this can be more easily evolved and contextualized.

    • -2
    • +2
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 60 more files in changeset.
Emit build operations around container callback executions (core and dependencyMgmt containers) (#7734)

* Decorate taskcontainer callbacks to track application id

* Decorate plugin container callbacks

* Decorate repositoryContainer callbacks

* Decoreate configurations and configuration.dependencies container callbacks

* Decorate artifactTypesDecorator callbacks

* Dont emit build ops for internal declared callbacks

* Provide usercode context in beforeResolve / afterResolve callbacks

* keep compatibility for nebula.dependency-recommender plugin

* Put domain collection callback build ops behind feature toggle

* Decorate Provider.configure() methods

* Simplify container callback filtering and decoration

Previously, we had three classes collaborating to achieve this but now this is inlined into effectively one. While this creates a more complex implementation, that is still rather simple, it avoids the more problematic complexity of a complicated relationship between the three implementations that also required extra state and details to be propagated through all of the collections.

    • -1
    • +2
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 70 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

    • -2
    • +2
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 64 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.

    • -19
    • +0
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 39 more files in changeset.
Do not pass variant attributes to `(single|multiple)Variants`

Instead, we make sure that the variant passed to the artifact set already contains the right set of

attributes. This involves wrapping the original `ComponentVariant` into a wrapper that will execute

the attribute rules lazily (and only once).

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

    • -7
    • +7
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 16 more files in changeset.
Pass variant attributes down to `DefaultArtifactSet` to avoid passing the rules there

This doesn't prevent the rules from being applied multiple times, but it will: now the

variant attributes are passed, meaning that once we cache the application of the rules,

they will only be computed once.

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

    • -7
    • +7
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 17 more files in changeset.
Rename the internal and test fixtures `VariantMetadata` to avoid confusion

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

    • -8
    • +8
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 25 more files in changeset.
Retain the value of a variant attribute as an isolated value, rather than retaining the original value. Attribute values are snapshot at the point where the attribute is registered and are isolated from further changes to the original value.

This change allows attribute matching to more safely happen in parallel and means that attribute values can behave more consistently with other features that use isolated and snapshot values, such as task inputs or artifact transforms.

    • -2
    • +2
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 18 more files in changeset.
Apply the attributes defined by artifact type metadata to a variant of something only when that something does not define any attributes already.

Added some Javadocs and unit test coverage.

    • -7
    • +36
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 4 more files in changeset.
Added a public API reachable from `DependencyHandler` that allows a plugin to define attributes that should be attached to artifacts with a given extension, for example when consuming a Maven module or files defined by a file dependency.

The intention is that this meta-data about artifact types would complement (and maybe serve as input for) additional meta-data attached to a Maven/Ivy/local module by various meta-data rules.

    • -0
    • +154
    ./DefaultArtifactTypeRegistryTest.groovy
  1. … 23 more files in changeset.