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
    ./external/model/DefaultMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./external/model/DependencyConstraintMetadataRulesTest.groovy
    • -1
    • +1
    ./external/model/VariantFilesMetadataRulesTest.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
    ./external/model/DefaultMavenModuleResolveMetadataTest.groovy
    • -1
    • +1
    ./external/model/DependencyConstraintMetadataRulesTest.groovy
    • -1
    • +1
    ./external/model/VariantFilesMetadataRulesTest.groovy
  1. … 10 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
    ./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
    ./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
    ./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
    ./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
    ./model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./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
    ./model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./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
    ./model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./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
    ./model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./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
    ./model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./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
    ./model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./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
    ./model/AttributeConfigurationSelectorTest.groovy
    • -12
    • +10
    ./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
    ./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
    ./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
    ./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
    ./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
    ./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
    ./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
    ./model/AttributeConfigurationSelectorTest.groovy
  1. … 26 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 34 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 44 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 44 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 44 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 44 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 43 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 43 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 42 more files in changeset.
Improve variant matching error messages

Error messages prove to be difficult to interpret from a user point of

view. This commit tries to improve the situation by doing a couple of

things:

1. describing more clearly what the consumer is asking for. This includes,

when possible (currently only in the Java ecosystem), interpreting the

consumer attributes as a human-readable description, instead of a raw

list of attributes.

2. giving more context when possible. In particular, sometimes we fail

with an ambiguous variant error selection, but we only list the remaining

candidates, not listing the ones which were actually discarded during

selection. This proved to be particularly complex to debug from various

users (plugin authors and end-users).

    • -5
    • +97
    ./model/AttributeConfigurationSelectorTest.groovy
    • -47
    • +48
    ./model/ComponentAttributeMatcherTest.groovy
    • -2
    • +2
    ./model/LocalComponentDependencyMetadataTest.groovy
  1. … 44 more files in changeset.
Proper extra attribute keys disambiguation

When attempting to disambiguate variants that have extra attributes

present, the code did not account for rich vs. desugared attributes.

Because previous disambiguation considered extra attributes already, we

can limit the extra keys disambiguation to checking the key presence,

untyped.

    • -8
    • +16
    ./model/ComponentAttributeMatcherTest.groovy
  1. … 1 more file in changeset.