ComponentAttributesRulesIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.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.

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.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.

    • -4
    • +4
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 35 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.

    • -4
    • +4
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 38 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.

    • -4
    • +4
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 38 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.

    • -4
    • +4
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 38 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.

    • -4
    • +4
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 33 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).

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 36 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).

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 46 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).

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 46 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).

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 46 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).

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 45 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).

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 45 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).

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 44 more files in changeset.
@RequiredFeature can be used as a repeated annotation

If used for a single feature, avoid annotation noise by not using the

composite annotation. This also avoids the confusion that the

@RequiredFeature annotation cannot be used independently

(no compile error but does not work).

I made the @RequiredFeatures annotation package-private as it is

only required by the compiler and the runner now.

Signed-off-by: Benjamin Muskalla <bmuskalla@gradle.com>

    • -15
    • +10
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 43 more files in changeset.
@RequiredFeature can be used as a repeated annotation

If used for a single feature, avoid annotation noise by not using the

composite annotation. This also avoids the confusion that the

@RequiredFeature annotation cannot be used independently

(no compile error but does not work).

I made the @RequiredFeatures annotation package-private as it is

only required by the compiler and the runner now.

Signed-off-by: Benjamin Muskalla <bmuskalla@gradle.com>

    • -15
    • +10
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 43 more files in changeset.
Adjust test fixtures and test to ivy behavior changes

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 38 more files in changeset.
Remove special casing of pure ivy in resolve tests

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 9 more files in changeset.
Remove special casing of pure ivy in resolve tests

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 11 more files in changeset.
Use ivy derivation rules in resolve tests

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 12 more files in changeset.
Use ivy derivation rules in resolve tests

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 12 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 15 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 18 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 20 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -22
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 20 more files in changeset.
Adjust tests and samples to new metadata sources defaults

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 95 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -2
    • +2
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 32 more files in changeset.
Reshuffle some tests into subpackages

This is just a refactoring of tests, to make it clearer: the base

package started to grow significantly.

    • -0
    • +491
    ./ComponentAttributesRulesIntegrationTest.groovy
  1. … 79 more files in changeset.