Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Use RegularFileProperty instead of Property<File>

This replacement is done on a field only useful when combined with a

feature flag and introduced in 6.4.

    • -1
    • +4
    ./locking/DefaultDependencyLockingProviderTest.groovy
    • -4
    • +3
    ./locking/LockFileReaderWriterTest.groovy
  1. … 7 more files in changeset.
Use RegularFileProperty instead of Property<File>

This replacement is done on a field only useful when combined with a

feature flag and introduced in 6.4.

    • -1
    • +4
    ./locking/DefaultDependencyLockingProviderTest.groovy
    • -4
    • +3
    ./locking/LockFileReaderWriterTest.groovy
  1. … 7 more files in changeset.
Do not create lockdir for unique lock file

The lock directory for multiple lock files was still created when using

the single lockfile. This changes the code to no longer create it in

that case.

Issue #12973

    • -0
    • +4
    ./locking/LockFileReaderWriterTest.groovy
  1. … 1 more file in changeset.
Do not create lockdir for unique lock file

The lock directory for multiple lock files was still created when using

the single lockfile. This changes the code to no longer create it in

that case.

Issue #12973

    • -0
    • +6
    ./locking/LockFileReaderWriterTest.groovy
  1. … 1 more file in changeset.
Sort configurations in single lock file

This will make sure resolution ordering or internal representation gives

a consistent output.

Fixes #12973

    • -0
    • +13
    ./locking/LockFileReaderWriterTest.groovy
  1. … 1 more file 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
    ./component/external/model/DefaultMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./component/external/model/DependencyConstraintMetadataRulesTest.groovy
  1. … 10 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
    ./component/external/model/DefaultMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./component/external/model/DependencyConstraintMetadataRulesTest.groovy
  1. … 10 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

    • -2
    • +2
    ./resolve/caching/ComponentMetadataRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/ComponentMetadataSupplierRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/CrossBuildCachingRuleExecutorTest.groovy
  1. … 18 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

    • -2
    • +2
    ./resolve/caching/ComponentMetadataRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/ComponentMetadataSupplierRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/CrossBuildCachingRuleExecutorTest.groovy
  1. … 18 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

    • -2
    • +2
    ./resolve/caching/ComponentMetadataRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/ComponentMetadataSupplierRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/CrossBuildCachingRuleExecutorTest.groovy
  1. … 20 more files in changeset.
Spike invalidating in-memory cache at the end of a build

    • -2
    • +2
    ./resolve/caching/ComponentMetadataRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/ComponentMetadataSupplierRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/CrossBuildCachingRuleExecutorTest.groovy
  1. … 20 more files in changeset.
Spike invalidating in-memory cache at the end of a build

    • -2
    • +2
    ./resolve/caching/ComponentMetadataRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/ComponentMetadataSupplierRuleExecutorTest.groovy
    • -2
    • +2
    ./resolve/caching/CrossBuildCachingRuleExecutorTest.groovy
  1. … 19 more files in changeset.
Align the ambiguous selection error messages with no matching case

This commit polishes improved error messages in variant selection by

making the "ambiguous" case closer to what we have for the "no matching"

case.

    • -23
    • +11
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 20 more files in changeset.
Align the ambiguous selection error messages with no matching case

This commit polishes improved error messages in variant selection by

making the "ambiguous" case closer to what we have for the "no matching"

case.

    • -23
    • +11
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 20 more files in changeset.
Align the ambiguous selection error messages with no matching case

This commit polishes improved error messages in variant selection by

making the "ambiguous" case closer to what we have for the "no matching"

case.

    • -23
    • +11
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 20 more files in changeset.
Align the ambiguous selection error messages with no matching case

This commit polishes improved error messages in variant selection by

making the "ambiguous" case closer to what we have for the "no matching"

case.

    • -23
    • +11
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 19 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -12
    • +17
    ./component/model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./component/model/LocalComponentDependencyMetadataTest.groovy
  1. … 37 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -12
    • +17
    ./component/model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./component/model/LocalComponentDependencyMetadataTest.groovy
  1. … 34 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -12
    • +17
    ./component/model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./component/model/LocalComponentDependencyMetadataTest.groovy
  1. … 37 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -12
    • +17
    ./component/model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./component/model/LocalComponentDependencyMetadataTest.groovy
  1. … 37 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -12
    • +17
    ./component/model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./component/model/LocalComponentDependencyMetadataTest.groovy
  1. … 37 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -12
    • +17
    ./component/model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./component/model/LocalComponentDependencyMetadataTest.groovy
  1. … 37 more files in changeset.
Introduce styled exceptions

This commit introduces the concept of _styled exceptions_, which basically

allow putting some emphasis on user facing error messages. Before this

change, exception messages were just plain text. It's now possible to have

exceptions which provide a rich styled output when an ANSI console is

available.

The attribute matching code has been adapted to make use of those new

exception types.

    • -12
    • +17
    ./component/model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./component/model/LocalComponentDependencyMetadataTest.groovy
  1. … 32 more files in changeset.
Make it possible to use an ecosystem describer in more cases

Before this commit the describer would only be used if the same set of attributes

was found. This means that if the consumer added, or removed, one attribute, we

would lose the benefit of better user error messages. With this change, we try

to find the _best matching_ describer, if any.

    • -19
    • +12
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 20 more files in changeset.
Make it possible to use an ecosystem describer in more cases

Before this commit the describer would only be used if the same set of attributes

was found. This means that if the consumer added, or removed, one attribute, we

would lose the benefit of better user error messages. With this change, we try

to find the _best matching_ describer, if any.

    • -19
    • +12
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 20 more files in changeset.
Make it possible to use an ecosystem describer in more cases

Before this commit the describer would only be used if the same set of attributes

was found. This means that if the consumer added, or removed, one attribute, we

would lose the benefit of better user error messages. With this change, we try

to find the _best matching_ describer, if any.

    • -19
    • +12
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 20 more files in changeset.
Make it possible to use an ecosystem describer in more cases

Before this commit the describer would only be used if the same set of attributes

was found. This means that if the consumer added, or removed, one attribute, we

would lose the benefit of better user error messages. With this change, we try

to find the _best matching_ describer, if any.

    • -19
    • +12
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 19 more files in changeset.
Improve error reporting for the Java ecosystem

This commit introduces improved error messages for the Java ecosystem

in case of variant matching errors.

    • -14
    • +14
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 26 more files in changeset.
Improve error reporting for the Java ecosystem

This commit introduces improved error messages for the Java ecosystem

in case of variant matching errors.

    • -14
    • +14
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 26 more files in changeset.
Improve error reporting for the Java ecosystem

This commit introduces improved error messages for the Java ecosystem

in case of variant matching errors.

    • -14
    • +14
    ./component/model/AttributeConfigurationSelectorTest.groovy
  1. … 26 more files in changeset.