ComponentReplacementIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Reshuffle some tests into subpackages

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

package started to grow significantly.

    • -453
    • +0
    ./ComponentReplacementIntegrationTest.groovy
  1. … 79 more files in changeset.
Implement variant derivation strategy

This commit changes how Maven metadata is derived into variants. Now we will

only derive variants if the Java plugin is applied (the "base Java" plugin).

This is implemented via a variant derivation strategy, and allows fixing

the problem that a native component is unlikely to find sense in the derivation

of Java variants. This fixes a bug where the native plugins wouldn't be able

to consume native libraries published on Maven repositories, without Gradle

metadata.

    • -0
    • +2
    ./ComponentReplacementIntegrationTest.groovy
  1. … 43 more files in changeset.
Do not permit stack-traces to be emitted by integration tests

    • -1
    • +0
    ./ComponentReplacementIntegrationTest.groovy
  1. … 1 more file in changeset.
Enable improved POM support by default

This commit makes the experimental flag `IMPROVED_POM_SUPPORT` the default.

The flag is still there for backwards compatibility but has effectively no

impact. As a consequence, the behavior of improved POM support is now the

default, which implies that:

- Maven dependencies packaged as `pom` or `jar` now have derived variants

(`compile` and `runtime`) and we properly choose between the variants based

on the consumer attributes

- platform dependencies using the `platform` and `enforcedPlatform` keywords

are enabled

Enabling improved POM support by default is a **breaking change**: there's

a risk that resolved dependencies is different, in particular because we

will now only include the `compile` dependencies of a POM file whenever the

consumer asks for the API variant. There are also some changes in the

dependency insight reports due to the use of attribute based matching instead

of configuration selection.

Last but not least, this commit is likely to introduce a small performance

regression due to attribute based selection.

    • -2
    • +5
    ./ComponentReplacementIntegrationTest.groovy
  1. … 50 more files in changeset.
Fix tests for changed reporting

    • -1
    • +0
    ./ComponentReplacementIntegrationTest.groovy
  1. … 1 more file in changeset.
Consistently report conflict resolution

This commit refactors how conflict resolution selection reasons are handled, in order to:

- collect the list of versions which participated in conflict resolution

- report a single conflict resolution cause when conflicts are resolved several times for the same module

- consistently report module replacement rules as rules, not conflict resolution. Before this change,

a module replacement was reported as both a conflict and a rule

    • -41
    • +82
    ./ComponentReplacementIntegrationTest.groovy
  1. … 29 more files in changeset.
Remove code which added a default reason when the first one wasn't expected

This code was probably leftover from a previous implementation which wasn't

collecting reasons properly. Now, it's possible that the first dependency

we see is actually a constraint, so the test didn't make sense.

It also fixes a rendering issue where multiple blank lines were added in

case of rendering extra sections.

    • -1
    • +0
    ./ComponentReplacementIntegrationTest.groovy
  1. … 4 more files in changeset.
Remove code which added a default reason when the first one wasn't expected

This code was probably leftover from a previous implementation which wasn't

collecting reasons properly. Now, it's possible that the first dependency

we see is actually a constraint, so the test didn't make sense.

It also fixes a rendering issue where multiple blank lines were added in

case of rendering extra sections.

    • -1
    • +0
    ./ComponentReplacementIntegrationTest.groovy
  1. … 4 more files in changeset.
Associate rejected versions with their constraint or rule

This commit reworks the mapping between rejected versions and

version selectors, so that we can make the difference between

a version which was rejected by a selector (regular or constraint)

or a rule. Then the dependency insight report can properly show

what versions were rejected in which context.

    • -3
    • +7
    ./ComponentReplacementIntegrationTest.groovy
  1. … 18 more files in changeset.
Associate rejected versions with their constraint or rule

This commit reworks the mapping between rejected versions and

version selectors, so that we can make the difference between

a version which was rejected by a selector (regular or constraint)

or a rule. Then the dependency insight report can properly show

what versions were rejected in which context.

    • -3
    • +7
    ./ComponentReplacementIntegrationTest.groovy
  1. … 18 more files in changeset.
Avoid duplicate details in dependencyInsight

Fixes #5397

    • -3
    • +0
    ./ComponentReplacementIntegrationTest.groovy
  1. … 4 more files in changeset.
Consistently use component level attributes

Component-level attributes were only used if the component metadata was using Gradle

metadata. This was particularly confusing, as it was possible to define a component-

level attribute in a component-metadata rule, but it would be ignored during matching.

It was possible, however, to add attributes on variants of Ivy or Maven metadata,

but then the error messages in case there wasn't any match was even more confusing:

"Because there are no configurations with attributes"

This commit modifies the resolution engine so that it's possible to use component

level attributes independently of whether the underlying component metadata was

constructed from Ivy, Maven or Gradle metadata. It also changes the error messages

to mention either "configuration" or "variant" depending on whether the matching

strategy was using variant-aware dependency management *or* legacy configurations.

It was confusing because we have the `IMPROVED_POM_SUPPORT` flag which activates

variant construction from Maven metadata. This meant that in practice, if the flag

was active, we were using variants, but still the component level attributes were

not taken into account. If the flag wasn't active, then we would fail with the

error above, despite the fact we had rules on "configuration backed variants".

The separation of configuration/variant in error messages makes it easier for

us to understand in which case we are, since this wasn't always obvious. If we

see "variant", then now we know that the selection failed using the variant-aware

matching. If we see "configuration", then we know it's using the legacy mode.

This commit also needed to make the difference between "this component has no

variant" and "this component doesn't provide any mapping to variants", therefore

the introduction of the `Optional` on `getVariantsForTraversal`. This gives us

the opportunity to give the correct error message in case of failure using

the legacy mode.

Last but not least, this introduces a change in the attributes visible on variants

**and** artifacts. Before this commit, dependending on whether metadata was

Gradle metadata, the "status" attribute would be found or not. Now, the component

level attributes are _always_ merged to variant and artifact attributes, which

means that it's consistent independently of the format. This can be a breaking

change, but a low risk one.

    • -2
    • +6
    ./ComponentReplacementIntegrationTest.groovy
  1. … 39 more files in changeset.
Introduce several methods on `ExecutionResult` and `ExecutionFailure` to allow a test to express various expectations about the logging output of the build, rather than scraping the `output` and `errorOutput` properties in the test.

Change several tests to use these fixture methods, plus fix several other tests for changes to the logging output.

    • -2
    • +1
    ./ComponentReplacementIntegrationTest.groovy
  1. … 21 more files in changeset.
Remove the `show-variant-details` flag

This commit removes the flag to enable variant details display, and

instead displays the variant details in every case. The rationale is

that usage of `dependencyInsight` is rare, and that without knowing

the existence of the flag, it's unlikely to be used. The additional

details also don't add too much overhead to the output, making it

reasonable to show the variant details by default.

    • -0
    • +2
    ./ComponentReplacementIntegrationTest.groovy
  1. … 4 more files in changeset.
Allow '+' character in module replacement input

Fixes #1472

    • -0
    • +8
    ./ComponentReplacementIntegrationTest.groovy
  1. … 2 more files in changeset.
Support custom selection reasons for module replacements

This commit adds the ability to use a custom selection reason when a module is replaced with

another.

Signed-off-by: Cedric Champeau <cedric@gradle.com>

    • -0
    • +42
    ./ComponentReplacementIntegrationTest.groovy
  1. … 7 more files in changeset.
Treat various kinds of dependency resolution failures in more consistent ways.

- When a non-lenient view is used as a task input, then propagate any failure to select a configuration in the dependency graph during task graph calculation, rather than suppressing these kinds of failures and propagating later when the files happen to be queried. This now happens consistently whether fluid dependencies are used or not. The only difference between these is how much of the graph is traversed at task graph calculation time.

- When a lenient view is used as a task input, suppress configuration selection failures during task graph calculation and instead present them in `ArtifactCollection.failures`. Do this consistently regardless of whether fluid dependencies are used or not. Previously this kind of failure was propagated during task graph calculation for lenient views.

Also changed the error message on resolution failure to include what kind of query was being performed at the time to trigger the failure.

From an implementation point of view, separated the handling of selection failures from the code that produces the legacy resolution result so that this handling can be reused when the legacy result is not required (such as, say, when calculating the task graph).

    • -2
    • +6
    ./ComponentReplacementIntegrationTest.groovy
  1. … 34 more files in changeset.
Removed ‘eachModule’ and ‘eachProject’ DSL variants for dependency substitution

    • -13
    • +13
    ./ComponentReplacementIntegrationTest.groovy
  1. … 9 more files in changeset.
Fixed deprecation in component replacement test

    • -13
    • +13
    ./ComponentReplacementIntegrationTest.groovy
Split specification of module-replacement rules into a separate ‘modules’ block. +review REVIEW-5136

    • -3
    • +3
    ./ComponentReplacementIntegrationTest.groovy
  1. … 15 more files in changeset.
Use a rule-based syntax for declaring module replacements +review REVIEW-5136

    • -3
    • +3
    ./ComponentReplacementIntegrationTest.groovy
  1. … 4 more files in changeset.
Component replacements - ensured that we can module-replace versions that are forced. Currently, there is a case when 'forced' version is 'conflict-resolved'. We have different story in the backlog to improve the selection reason for the module-replaced components. For now, module-replaced components are considered 'conflict resolved' which essentially is correct.

+review REVIEW-5136

    • -0
    • +7
    ./ComponentReplacementIntegrationTest.groovy
  1. … 2 more files in changeset.
Component replacements - added an ignored integ test for consideration.

+review REVIEW-5136

    • -0
    • +7
    ./ComponentReplacementIntegrationTest.groovy
Component replacements: added new feature. Now it is possible to replace multiple modules with the same replacement target. I haven't created any new DSL for this because it is not needed - one can declare this case using the current DSL (we could add something better for this later if needed).

    • -0
    • +12
    ./ComponentReplacementIntegrationTest.groovy
  1. … 2 more files in changeset.
Component replacements, added more integration tests, also for the not-implemented yet feature.

    • -0
    • +28
    ./ComponentReplacementIntegrationTest.groovy
Added one more integration test to the component replacement test class.

    • -2
    • +11
    ./ComponentReplacementIntegrationTest.groovy
Component replacements. Ensured that the dependency resolve rules coexist neatly with component replacement. Added integ test coverage.

    • -0
    • +54
    ./ComponentReplacementIntegrationTest.groovy
Component replacements - ensured that the dependency exclusion rules coexist neatly with component replacement. It did not require changing any code - I added the integ test coverage.

    • -1
    • +14
    ./ComponentReplacementIntegrationTest.groovy
Component replacements - added integ test cases related to incorrect input supplied by the user.

    • -3
    • +23
    ./ComponentReplacementIntegrationTest.groovy
  1. … 2 more files in changeset.
Component replacements - added more integ test cases, rename job, some documentation.

    • -0
    • +19
    ./ComponentReplacementIntegrationTest.groovy
  1. … 3 more files in changeset.