DefaultMutableIvyModuleResolveMetadataTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -7
    • +0
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 39 more files in changeset.
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -7
    • +0
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 38 more files in changeset.
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -7
    • +0
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 39 more files in changeset.
Introduce module metadata verification

This commit introduces verification of metadata files.

For this, another refactoring of the `ModuleSource` concept

was required. Ironically, before this commit, `ModuleSource`

used to be available for serialization in the module metadata

serializer. However, they weren't used in practice, because

all the required data could be reconstructed from the caches.

In particular, there was this "contentHash" which, because

not properly serialized, was actually set as a field on the

component resolve metadata itself, instead of being part

of the module source.

Now, this commit reintroduces serialization of module sources

but takes a different approach by splitting the module sources

in two distinct categories:

- module sources which can be reconstructed from known data,

such as the repository name and repository url

- module sources which have to be serialized alongside component

metadata, because they can't be reconstructed from sources

The latter category includes this "contentHash", serialized with

the descriptor hash module source. It also includes the information

about _which_ actual descriptor file was used to generate the

binary module descriptor (e.g, the source POM, Ivy or module

metadata file). This information does _not_ belong to the module

component resolve metadata itself, so it belongs to its sources.

For this purpose, serialization of module sources has been updated

so that instead of using Java serialization, module sources need

to provide a custom serializer, called a Codec. Those codecs are

uniquely identified by an id which is just an integer. This is

done for performance optimization, in order to avoid to serialize

the name of the codec and have to load it dynamically. Instead,

Gradle knows about the full set of serializers (and there's no

way for a user to add more because in any case it would require

an update of the module metadata store format).

This makes it much more efficient to serialize module sources

(because we can now have an optimized encoder), but it also

permits reconstructing module sources from incomplete information.

In particular, the module source which describes the file from

which a component resolve metadata was sourced contains a link

to the actual file in the local artifact store. However, in order

to be relocatable, we _don't_ want this file path to be stored

in the metadata cache. This means that instead of storing the

path, we actually store the artifact identifier and the hash

of the descriptor so that we can, when loaded from cache, find

its location back.

Currently, metadata verification is enabled for all components.

It's not possible to disable verification of metadata.

    • -7
    • +0
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 39 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

    • -19
    • +21
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 64 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

    • -19
    • +20
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 62 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

    • -19
    • +21
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 64 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

    • -19
    • +21
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 64 more files in changeset.
Refactor `ModuleSource`

The `ModuleSource` concept was a bit messy. It was designed in order

to be able to store the origin of an artifact. Over time, it evolved

into storing more information, like snapshot timestamps, repositories

or content hash.

The code was convoluted because each part of the code was expecting

some kind of module source, but because of delegation, it wasn't

really possible to add/mix more sources.

This commit refactors this concept into a `ModuleSources` concept

which allows storing more information about a module source, in

a safe and consistent manner. No more wrapping/unwrapping, and each

code requiring a specific type of module source can query for it.

    • -19
    • +20
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 63 more files in changeset.
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

    • -1
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  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
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  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
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  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
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 16 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

    • -3
    • +2
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 30 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

    • -3
    • +2
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 32 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

    • -3
    • +2
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 32 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

    • -3
    • +2
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 32 more files in changeset.
Remove unused legacy code that looks for variants by name

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

    • -2
    • +2
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 64 more files in changeset.
Use an `ImmutableSet` to represent the configuration hierarchy

ImmutableSets are ordered and optimized for lookups. We happen to

call `contains` a lot on hierarchies, so using a `Set` should

optimize things a little.

    • -1
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 31 more files in changeset.
Rename method to better indicate meaning

The hash value returned by getOriginalContentHash() is the one from the

metadata parsed from a repository. It does not reflect any of the

potential mutations that happened to it at later stages.

The new name indicates this better.

    • -1
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 9 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.

    • -8
    • +8
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 164 more files in changeset.
Rename id accessors for consistency

Use `ComponentIdentifier getId()`

Use `ModuleVersionIdentifier getModuleVersionId()`

    • -19
    • +19
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 67 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
    • +2
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  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.

    • -13
    • +11
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 26 more files in changeset.
Remove unused fields

    • -1
    • +1
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 7 more files in changeset.
Rework `DefaultMutableIvyModuleResolveMetadata` constructors for consistency

Introduce constants where it makes sense and use consistent order of parameters.

    • -3
    • +3
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 5 more files in changeset.
Remove ability update Excludes on metadata

This functionality wasn't required, and was adding complexity.

    • -35
    • +6
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 6 more files in changeset.
Remove method that forces all ConfigurationMetadata to be instantiated up-front

This method is only used in tests, and makes it more difficult to build

configuration instances on-demand.

    • -2
    • +2
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 2 more files in changeset.
Construct ConfigurationMetadata instances when creating immutable resolve metadata

Previously, the mutable types would construct ConfigurationMetadata instances, and

invalidate them on change to the inputs. With this change, creating an (immutable)

ConfigurationMetadata instance happens when constructing an immutable

ModuleComponentResolveMetadata.

    • -4
    • +0
    ./DefaultMutableIvyModuleResolveMetadataTest.groovy
  1. … 10 more files in changeset.