VariantFilesMetadataRulesTest.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
    ./VariantFilesMetadataRulesTest.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
    ./VariantFilesMetadataRulesTest.groovy
  1. … 12 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant() (#11565)

    • -3
    • +27
    ./VariantFilesMetadataRulesTest.groovy
  1. … 10 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant()

    • -3
    • +27
    ./VariantFilesMetadataRulesTest.groovy
  1. … 10 more files in changeset.
Add lenient version of ComponentMetadataDetails.addVariant()

    • -3
    • +3
    ./VariantFilesMetadataRulesTest.groovy
  1. … 9 more files in changeset.
Fix NPE and tests

    • -0
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 6 more files in changeset.
Fix NPE and tests

    • -0
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 5 more files in changeset.
Use a different 'shadow capability' for enforced platform

This allows both 'regular' and 'enforced' platform of the same

component to be selected. In order to make this work, support

for projects having shadow capability needed to be added.

    • -0
    • +1
    ./VariantFilesMetadataRulesTest.groovy
  1. … 12 more files in changeset.
Always apply all Category disambiguation rules

Before, parts of the platform disambiguation were only done when

using the 'java-platform' plugin. However, other consumers

may also require all rules (see #11091)

    • -1
    • +0
    ./VariantFilesMetadataRulesTest.groovy
  1. … 6 more files in changeset.
Always apply all Category disambiguation rules

Before, parts of the platform disambiguation were only done when

using the 'java-platform' plugin. However, other consumers

may also require all rules (see #11091)

    • -1
    • +0
    ./VariantFilesMetadataRulesTest.groovy
  1. … 6 more files in changeset.
Always apply all Category disambiguation rules in Java ecosystem

Before, parts of the platform disambiguation were only done when

using the 'java-platform' plugin. However, consumers using other

Java plugins may also require all rules (see #11091)

    • -1
    • +0
    ./VariantFilesMetadataRulesTest.groovy
  1. … 5 more files in changeset.
Remove derived enforced-platform variants

Instead, implement them with strict versions for external modules.

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

Instead, implement them with strict versions for external modules.

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

Instead, implement them with strict versions for external modules.

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

Instead, implement them with strict versions for external modules.

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

Instead, implement them with strict versions for external modules.

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

This reverts commit 67b8bb8f18f854f45a2f5ec52cc9c8a25981e2f2.

This restores the merge attempt from earlier.

    • -1
    • +1
    ./VariantFilesMetadataRulesTest.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
    ./VariantFilesMetadataRulesTest.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
    ./VariantFilesMetadataRulesTest.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
    ./VariantFilesMetadataRulesTest.groovy
  1. … 16 more files in changeset.
Make evaluation of base variant rules lazy

    • -1
    • +34
    ./VariantFilesMetadataRulesTest.groovy
  1. … 6 more files in changeset.
Make evaluation of base variant rules lazy

    • -0
    • +33
    ./VariantFilesMetadataRulesTest.groovy
  1. … 6 more files in changeset.
Add removeAllFiles() to variant files modification API

Files from an existing 'base' are now also transferred to the new

variant (but can then be removed with removeAllFiles()). This makes:

- The behavior more consistent (before everything was transferred

*except* for the files)

- The 'enrich plain ivy with variants' use case better as you do not

manually have to re-add the files that are already in the configuration

metadata

    • -1
    • +30
    ./VariantFilesMetadataRulesTest.groovy
  1. … 14 more files in changeset.
Add removeAllFiles() to variant files modification API

Files from an existing 'base' are now also transferred to the new

variant (but can then be removed with removeAllFiles()). This makes:

- The behavior more consistent (before everything was transferred

*except* for the files)

- The 'enrich plain ivy with variants' use case better as you do not

manually have to re-add the files that are already in the configuration

metadata

    • -1
    • +30
    ./VariantFilesMetadataRulesTest.groovy
  1. … 12 more files in changeset.
Add removeAllFiles() to variant files modification API

Files from an existing 'base' are now also transferred to the new

variant (but can then be removed with removeAllFiles()). This makes:

- The behavior more consistent (before everything was transferred

*except* for the files)

- The 'enrich plain ivy with variants' use case better as you do not

manually have to re-add the files that are already in the configuration

metadata

    • -1
    • +30
    ./VariantFilesMetadataRulesTest.groovy
  1. … 14 more files in changeset.
Add API method to ad a variant without base

Also extend documentation about 'base' and throw errors if a

non-existing base is defined.

    • -1
    • +20
    ./VariantFilesMetadataRulesTest.groovy
  1. … 6 more files in changeset.
Add API method to ad a variant without base

Also extend documentation about 'base' and throw errors if a

non-existing base is defined.

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

    • -0
    • +238
    ./VariantFilesMetadataRulesTest.groovy
  1. … 32 more files in changeset.
Add support for adding variants and files to component metadata rules

    • -0
    • +237
    ./VariantFilesMetadataRulesTest.groovy
  1. … 32 more files in changeset.
Add support for adding variants and files to component metadata rules

    • -0
    • +237
    ./VariantFilesMetadataRulesTest.groovy
  1. … 31 more files in changeset.