Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

  1. … 27 more files in changeset.
Do not drop variant attributes for 'traditional' maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

  1. … 13 more files in changeset.
Do not drop variant attributes for 'traditional' maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

Fixes for previous commit.

Fixes for previous commit.

Fixes for previous commit.

Fixes for previous commit.

Clean up worker composite test

Only do maven artifact discovery for variants that require it

Only do maven artifact discovery for variants that require it

Only do maven artifact discovery for variants that require it

Only do maven artifact discovery for variants that require it

Only do maven artifact discovery for variants that require it

Let resolved variants remember if they were derived

Prepare for 5.6.1

    • -0
    • +2
    /subprojects/docs/src/docs/release/notes.md
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

Setters for legacy properties backed by Property clear conventions

The version property of a archive task by convention is set to

project.version.

In previous releases, archiveTask.version = null would clear the

value of version and we would strip this from the archive file name.

In Gradle 5.6, setting a Property's value to null reverts back to

the convention's value.

To mimic the old behavior, using the legacy setter now overwrites

both the value and the convention. So when setting the property

explicitly to null, the underlying Property now has a null value.

Ensure that no-isolation workers run with the classloader of the submitting thread

This fixes a problem where, in a composite build, a worker can get a context

classloader set to a classloader from another project, which causes a class

mismatch when we attempt to re-hydrate a legacy runnable class in AdapterWorkAction.

We now ensure that the context classloader for no-isolation workers get set

to the context classloader of the thread that submitted the work.

    • -0
    • +1
    /subprojects/workers/workers.gradle.kts
Add support for adding variants and files to component metadata rules

  1. … 18 more files in changeset.
Add support for adding variants and files to component metadata rules

  1. … 18 more files in changeset.
Add support for adding variants and files to component metadata rules

  1. … 11 more files in changeset.
Add support for adding variants and files to component metadata rules