ComponentResultSerializerTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Make selected variant accessible on dependency

For resolved dependency results, we now tell what

is the corresponding selected variant.

    • -13
    • +17
    ./ComponentResultSerializerTest.groovy
  1. … 24 more files in changeset.
Make selected variant accessible on dependency

For resolved dependency results, we now tell what

is the corresponding selected variant.

    • -13
    • +17
    ./ComponentResultSerializerTest.groovy
  1. … 24 more files in changeset.
Replace most usages of `NamedObjectInstantiator.INSTANCE` with injection of a global service instead. This allows the instantiator to be contextualized, for example to handle caching of the generated types.

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
  1. … 25 more files in changeset.
Replace most usages of `NamedObjectInstantiator.INSTANCE` with injection of a global service instead. This allows the instantiator to be contextualized, for example to handle caching of the generated types.

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
  1. … 27 more files in changeset.
Replace most usages of `NamedObjectInstantiator.INSTANCE` with injection of a global service instead. This allows the instantiator to be contextualized, for example to handle caching of the generated types.

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
  1. … 27 more files in changeset.
Replace most usages of `NamedObjectInstantiator.INSTANCE` with injection of a global service instead. This allows the instantiator to be contextualized, for example to handle caching of the generated types.

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
  1. … 27 more files in changeset.
Initial support for optional features

This commit introduces initial support for optional features, by

implementing a way for a dependency declaration (currently *only* in

the DSL) to request variants of the target component that provide one

or more capabilities.

Previously to this change, selection was (simplified) done like this:

1. find the target component

2. select the variant of the target component which matches the requested

attributes

Now, selection introduces another step:

1. find the target component

2. filter variants by eliminating those which do not provide the requested

capabilities

3. select the variant in this list which matches the requested attributes

Several changes had to be implemented:

First, component metadata rules calling `addCapability` will now return

a component which capabilities _include_ the default capability.

Second, attribute filtering is done in a secondary step, which means that

if there are no variant matching the requested capabilities, we will immediately

fail.

    • -0
    • +22
    ./ComponentResultSerializerTest.groovy
  1. … 58 more files in changeset.
Support depending on multiple variants of the same component

This commit changes the resolution engine so that it is possible

to resolve multiple variants of the same component when using

variant-aware dependency management.

Before, in order to have 2 dependencies on the same component

but using different variants, one had to use explicit configuration

dependencies. Now, with this change, it is possible to have

two dependencies on the same component, but with different attributes.

Those components would resolve to different variants.

Special treatment is applied when attributes are declared on constraints:

in this case, we _merge_ the constraint attributes, and make sure that

the edge is computed using the merged attributes. Should they be

incompatible, the build would fail as before.

    • -4
    • +17
    ./ComponentResultSerializerTest.groovy
  1. … 29 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

    • -3
    • +3
    ./ComponentResultSerializerTest.groovy
  1. … 64 more files in changeset.
Renamed `VersionSelectionReasons` -> `ComponentSelectionReasons`

    • -2
    • +2
    ./ComponentResultSerializerTest.groovy
  1. … 30 more files in changeset.
Add support for emitting information about repositories used during configuration resolution process, and sourced repository for a component (#5959)

- `ResolveConfigurationDependenciesBuildOperationType.Details` now contains a `List<Repository>` eventually provided by all `ResolutionAwareRepository` implementations

- `ResolvedComponentResult` has been subclassed to `ResolvedComponentResultInternal`, to provide the `repositoryName` used as source. This can be `null` in case of project dependency.

- Note that even when artifacts are resolved from the cache, they still convey the original repository that was used as source. The `name` of a repository is guaranteed to be unique inside a given repository container, and we use a single repository container to resolve a given configuration. Hence, the name can be safely used to uniquely identify which repository was used to source components.

- This commit also moves custom serialization logic to the owning type of `SerializedOperation` implementations to their owning types

    • -3
    • +5
    ./ComponentResultSerializerTest.groovy
  1. … 52 more files in changeset.
Improved name and documentation of attribute container serializer

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 10 more files in changeset.
Normalize `ModuleIdentifier`

This commit reworks the `ComponentModuleIdentifier`/`ComponentModuleSelector`/`ModuleVersionSelector`

classes to use `ModuleIdentifier` under the hood, instead of storing denormalized strings. This has

the advantage that we can reduce the use of the module identifier factory, which is called very

often during dependency resolution. Sharing instances reduces the need for conversions, and makes

comparisons faster.

    • -1
    • +2
    ./ComponentResultSerializerTest.groovy
  1. … 164 more files in changeset.
Add a non lossy AttributeContainer serializer

This will be required for supporting the serialization of a fully

realised ModuleComponentResolveMetadata.

Issue #5653

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 8 more files in changeset.
Add a non lossy AttributeContainer serializer

This will be required for supporting the serialization of a fully

realised ModuleComponentResolveMetadata.

Issue #5653

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 8 more files in changeset.
Avoid eager creation of display name for variants

In a lot of cases, we were eagerly concatenating strings in `visitFile` even if the name was never used.

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 24 more files in changeset.
Revert "Revert "Merge pull request #4651 from gradle/dd/dependency-management/engine-refactor-and-docs""

This reverts commit de96eee53bfa39a73818186cc3bbd006a2cfb04a.

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 14 more files in changeset.
Revert "Merge pull request #4651 from gradle/dd/dependency-management/engine-refactor-and-docs"

This reverts commit 06abfbb7db5d652e4aaae3f262178f93328cd410, reversing

changes made to e581b30fc8dd70ba4939737c03cce42bcb15e86c.

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 14 more files in changeset.
Renamed `DefaultComponentResult` -> `DetachedComponentResult`

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 4 more files in changeset.
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>

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

    • -2
    • +14
    ./ComponentResultSerializerTest.groovy
  1. … 25 more files in changeset.
Cache module version identifiers

In a similar way to module identifiers, use the module identifier factory to cache the module version identifiers.

It allows faster comparisons as we will hit `a==b` much more often and don't have to go the `equals` route. There

are still places where the factory is not used, but it doesn't seem to have a huge impact on performance.

    • -1
    • +2
    ./ComponentResultSerializerTest.groovy
  1. … 49 more files in changeset.
Revert De-duplicate commonly used immutable objects in dependency resolution and IDE changes

Commits reverted:

- 807b1e4f8d1585d93c1de3e9ca83d99d0819e2d2

- 9482b0b05374253cafdb776550d7016385912e04

- 4ecead06b53ec6b0f15c517bf0d0c6a74c3b3c05

- db1135a8a5f1c507e0df3c03ad12ddc963799e4d

- 7350bcbae30a777909cec74ebfd5a91d2c89081e

Additionally, minor changes to avoid usage of introduced

classes and methods from subsequent commits.

Issue: gradle/gradle-private#563

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 109 more files in changeset.
De-duplicate (= intern) some instances in dependency resolution

- Reduce memory usage of dependency resolution by de-duplicating the

most commonly used immutable instances.

- Objects aren't strictly immutable: displayName is calculated lazily

- solution is thread-safe without synchronization

- lazy calculation is needed for efficient interning since a lookup

will always create a new instance.

- Use strong references in some instance interners

- strong references cause less GC overhead than weak references

- Strong references:

DefaultModuleIdentifier

DefaultModuleVersionIdentifier

DefaultModuleVersionSelector

DefaultModuleComponentIdentifier

DefaultModuleComponentSelector

DefaultProjectComponentSelector

- Weak references:

DefaultLibraryBinaryIdentifier

DefaultLibraryComponentSelector

DefaultIvyArtifactName

- Both reference types:

DefaultBuildIdentifier

DefaultProjectComponentIdentifier

- The reason for special handing is that DefaultBuildIdentifier

has a state field "current" as part of the instance which

isn't part of equals/hashCode.

+review REVIEW-6277

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 104 more files in changeset.
Renamed`id` to `moduleVersion` in dependency resolve results `ComponentResult` to make more explicit that this is simply a bucket of attributes, not an identifier for the component.

    • -1
    • +1
    ./ComponentResultSerializerTest.groovy
  1. … 11 more files in changeset.
Use more efficient serialization for the resolution result of a configuration.

    • -1
    • +2
    ./ComponentResultSerializerTest.groovy
  1. … 18 more files in changeset.
Renamed some classes.

    • -0
    • +40
    ./ComponentResultSerializerTest.groovy
  1. … 24 more files in changeset.