DefaultMavenModuleResolveMetadataTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Consider the derivation strategy when requesting component metadata

Gradle has a single, build scoped cache for dependency metadata. It's

using a build cache scope because component metadata is quite expensive

to read and process. However, component metadata _may_ be different

based on the plugins applied on a project. For example, Java projects

apply what we call a "Java derivation strategy", which is capable

of transforming regular POM files into so-called "platforms" but

more importantly, they are what map the different Maven scopes to

actual "variants" in variant-aware dependency management.

The problem is that it's not a requirement that all projects are

Java projects. It is possible to have native subprojects, or projects

which do _not_ apply the Java base plugin. While it's in general an

error to have a project which wants to perform "Java dependency

resolution" not to apply the Java derivation strategy, there are

consequences in not doing so. In particular, Gradle becomes order

dependent: if a subproject which does not apply the derivation

strategy resolves a module first, then subsequent resolutions for

projects which _do_ apply the derivation strategy would get wrong

metadata.

To avoid this, this commit makes sure that when we consume module

metadata, we actually use the derivation strategy as part of the

processed metadata cache key.

This does _not_ fix the fact that the consumers _should have_ applied

the derivation strategy and will make realizing this harder, but it

_does_ fix the inconsistency in resolution, which is probably a

much bigger issue (for caching and reproducibility).

    • -1
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 12 more files in changeset.
Consider the derivation strategy when requesting component metadata

Gradle has a single, build scoped cache for dependency metadata. It's

using a build cache scope because component metadata is quite expensive

to read and process. However, component metadata _may_ be different

based on the plugins applied on a project. For example, Java projects

apply what we call a "Java derivation strategy", which is capable

of transforming regular POM files into so-called "platforms" but

more importantly, they are what map the different Maven scopes to

actual "variants" in variant-aware dependency management.

The problem is that it's not a requirement that all projects are

Java projects. It is possible to have native subprojects, or projects

which do _not_ apply the Java base plugin. While it's in general an

error to have a project which wants to perform "Java dependency

resolution" not to apply the Java derivation strategy, there are

consequences in not doing so. In particular, Gradle becomes order

dependent: if a subproject which does not apply the derivation

strategy resolves a module first, then subsequent resolutions for

projects which _do_ apply the derivation strategy would get wrong

metadata.

To avoid this, this commit makes sure that when we consume module

metadata, we actually use the derivation strategy as part of the

processed metadata cache key.

This does _not_ fix the fact that the consumers _should have_ applied

the derivation strategy and will make realizing this harder, but it

_does_ fix the inconsistency in resolution, which is probably a

much bigger issue (for caching and reproducibility).

    • -1
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 12 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.

    • -21
    • +0
    ./DefaultMavenModuleResolveMetadataTest.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.

    • -21
    • +0
    ./DefaultMavenModuleResolveMetadataTest.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.

    • -21
    • +0
    ./DefaultMavenModuleResolveMetadataTest.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.

    • -21
    • +0
    ./DefaultMavenModuleResolveMetadataTest.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.

    • -21
    • +0
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 63 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 19 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 19 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 19 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 19 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

    • -7
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 19 more files in changeset.
Revert "Revert "Merge branch 'release'""

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

    • -3
    • +3
    ./DefaultMavenModuleResolveMetadataTest.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.

    • -3
    • +3
    ./DefaultMavenModuleResolveMetadataTest.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

    • -3
    • +3
    ./DefaultMavenModuleResolveMetadataTest.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.

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

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

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

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

    • -5
    • +4
    ./DefaultMavenModuleResolveMetadataTest.groovy
  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.

    • -2
    • +1
    ./DefaultMavenModuleResolveMetadataTest.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
    • +1
    ./DefaultMavenModuleResolveMetadataTest.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
    • +1
    ./DefaultMavenModuleResolveMetadataTest.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
    • +1
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 27 more files in changeset.
Update Category attribute to be typed

Adapt code to new typed attributes, dealing with coercible String values

when parsed from metadata and typed values when created inside a Gradle

build.

    • -2
    • +2
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 21 more files in changeset.
Update Category attribute to be typed

Adapt code to new typed attributes, dealing with coercible String values

when parsed from metadata and typed values when created inside a Gradle

build.

    • -2
    • +2
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 21 more files in changeset.
Update Category attribute to be typed

Adapt code to new typed attributes, dealing with coercible String values

when parsed from metadata and typed values when created inside a Gradle

build.

    • -2
    • +2
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 18 more files in changeset.
Update Category attribute to be typed

Adapt code to new typed attributes, dealing with coercible String values

when parsed from metadata and typed values when created inside a Gradle

build.

    • -2
    • +2
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 21 more files in changeset.
Update Category attribute to be typed

Adapt code to new typed attributes, dealing with coercible String values

when parsed from metadata and typed values when created inside a Gradle

build.

    • -2
    • +2
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 27 more files in changeset.
Update Category attribute to be typed

Adapt code to new typed attributes, dealing with coercible String values

when parsed from metadata and typed values when created inside a Gradle

build.

    • -2
    • +2
    ./DefaultMavenModuleResolveMetadataTest.groovy
  1. … 27 more files in changeset.