ModuleMetadataSerializerTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

  1. … 66 more files in changeset.
Revert "Merge branch 'release'"

This reverts commit c7fdc455dcb9a8016af0ae9bc8b4c43fde1e2d06, reversing

changes made to 9f70d52b74dbc8c71381781b6c155474031b3cf8.

The changes need a wrapper as there are API changes. Reverting for now.

  1. … 66 more files in changeset.
Changes in Gradle Module Metadata loading

We no longer define any configurations, like default or the maven ones.

In the past, we still had these defined which allowed partial legacy

selection. But it made no sense since all these configurations would not

have any dependencies for example.

Fixes #10980

  1. … 16 more files in changeset.
Changes in Gradle Module Metadata generation

We no longer define any configurations, like default or the maven ones.

In the past, we still had these defined which allowed partial legacy

selection. But it made no sense since all these configurations would not

have any dependencies for example.

  1. … 16 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

  1. … 30 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

  1. … 32 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

  1. … 32 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

  1. … 32 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.

  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.

  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.

  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.

  1. … 27 more files in changeset.
Rename writer/parser classes for consistency

  1. … 21 more files in changeset.
Further deduplication of serialized metadata

Maven dependency metadata de-duplication now happens as well when

serializing untransformed metadata.

Fixes #8311

  1. … 7 more files in changeset.
Implement Gradle metadata marker in published pom/ivy files

This commit implements a performance optimization for Gradle metadata.

Given that today there's no library published in any repository with

Gradle metadata, it's much more likely to find a POM (or Ivy) metadata

file for an external dependency, rather than a Gradle metadata file.

If we decided to add `gradleMetadata()` sources by default to all

repositories, then we would probably introduce a performance regression

to a lot of builds, because we would first try to get Gradle metadata,

then fail, and search for POM/Ivy files.

To avoid this, whenever a library is going to be published with Gradle

metadata, we will introduce a _marker_ in the published POM or Ivy

file. When Gradle _resolves_ such a dependency, it will parse the POM

file and look for the marker. If it finds it, then it will _redirect_

to use Gradle metadata instead. This means that when Gradle metadata is

present, we will pay the price of looking for a POM or Ivy file first,

start parsing, only to discover we should parse Gradle metadata. This

should be ok in the beginning, knowing that if `gradleMetadata()` is

added, then we would systematically look at Gradle metadata first.

This means that this is a _temporary_ solution, until Gradle metadata

becomes widespread. So "temporary" should be understood as several

months, if not years.

The marker introduced in POM and Ivy files is _neutral_ for both Ivy

and Maven. By this we mean that it uses an XML comment. While not super

nice, we couldn't use a custom namespace because both Ivy and Maven

fail when parsing this. Properties were considered too, but Ivy doesn't

support them so for consistency both models use comments.

It's worth noting that we will still _completely parse_ the POM or Ivy

descriptor. It's a waste of time, but it helps in case we find a marker

but that for some reason the Gradle metadata file is absent. In this

case we fallback on the model we found.

This change also introduces a change in the semantics of the incubating

metadata sources API: those should be considered _hints_, and not strong

statements anymore.

Finally, should a producer want to avoid publishing Gradle metadata,

it's now possible to disable the task that creates the metadata file.

  1. … 57 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

  1. … 64 more files in changeset.
Improved name and documentation of attribute container serializer

  1. … 10 more files in changeset.
Refactor ModuleResolveMetadata

Reorganize code in packages, move serialization related code closer to

classes to reduce need of public methods.

  1. … 79 more files in changeset.
Refactor ModuleResolveMetadata

Reorganize code in packages, move serialization related code closer to

classes to reduce need of public methods.

  1. … 79 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. … 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. … 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. … 8 more files in changeset.
Cache parsing of version strings

The version parser is by far the largest contributor to garbage created during the

resolution of a large dependency graph. This commit creates a build scope version

parser which is shared and caches the result of parsing, avoiding the creation of

a significant number of arrays.

  1. … 45 more files in changeset.
Rename 'experimental features' to 'feature previews'

The idea behind this is that we have a set of feature previews rather

than one cryptic experimental flag.

A feature preview collects a set of related functionality (e.g.

everything related to gradle metadata) that changes existing behavior

and thus could potentially break existing builds. The preview options

will be removed with the next major release (currently 5.0) and the new

behaviour will then become the default.

Signed-off-by: Jendrik Johannes <jendrik@gradle.com>

  1. … 45 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.
Provide additional services to constructor calls in tests

Signed-off-by: Jendrik Johannes <jendrik@gradle.com>

  1. … 14 more files in changeset.
Initial implementation of component metadata rules allowing modification of variant attributes

This commit introduces metadata rules that support modification of variant attributes. Variant attributes

are specific to each variant and can be found in module metadata. Those are NOT component level attributes,

which could be used during dependency resolution. This will be added in a subsequent commit.

  1. … 49 more files in changeset.
Create all mutable Ivy module resolve metadata through factory

This will simplify the injection of services through the factory, when we will need the immutable

attributes factory to be pushed to resolve metadata.

  1. … 26 more files in changeset.
Instantiate mutable Maven metadata through dependency injecting instantiator

This commit prepares the ability to inject services into mutable Maven metadata. This will be

required to inject the immutable attributes factory, as well as the object instantiator and

possibly other services to the immutable Maven resolve metadata. This commit reduces the

number of constructors of `DefaultMavenModuleResolveMetadata`, to make it easier to maintain.

Some tests still create mutable module resolve metadata directly. Ideally, they should also

use the factory.

  1. … 19 more files in changeset.
Make sure that published component attributes can also be mutated

This commit adds support for serialization of component level attributes. Before, the module metadata descriptor

could contain attributes, but since we never used them, apart from the hard-coded `status` attribute, there was

no need to serialize them in binary format. Now, it is possible for a consumer to overwrite component attributes,

including custom attributes. This makes necessary for serializing this information.

However, this commit does NOT add support for publishing component attributes: at this point, while there's a way

to _consume_ attributes, there's no way to _publish_ them.

    • -0
    • +16
    ./ModuleMetadataSerializerTest.groovy
  1. … 10 more files in changeset.