VersionConflictResolutionIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
failing test!

Signed-off-by: Dan Sanduleac <sanduleac.dan@gmail.com>

    • -7
    • +18
    ./VersionConflictResolutionIntegrationTest.groovy
failing test!

Signed-off-by: Dan Sanduleac <sanduleac.dan@gmail.com>

    • -7
    • +18
    ./VersionConflictResolutionIntegrationTest.groovy
Currently passing test

Signed-off-by: Dan Sanduleac <sanduleac.dan@gmail.com>

    • -0
    • +42
    ./VersionConflictResolutionIntegrationTest.groovy
Currently passing test

Signed-off-by: Dan Sanduleac <sanduleac.dan@gmail.com>

    • -0
    • +42
    ./VersionConflictResolutionIntegrationTest.groovy
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.

    • -3
    • +2
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 43 more files in changeset.
Remove unused improve pom support flags

    • -3
    • +0
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 19 more files in changeset.
Tidy up variant-names in integration tests

Instead of inlining the expected variant name in the module coordinates,

use `ResolveTestFixture.expectDefaultConfiguration(variant)`.

    • -21
    • +21
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 8 more files 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.

    • -16
    • +16
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 50 more files in changeset.
Ability to revert a dependency to pending

This change covers one more edge case where the dependency causing the

status revert happens to itself declare an optional dependency to the

reverting module.

Fixes #6604

    • -1
    • +8
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 3 more files in changeset.
Ability to revert a dependency to pending

This changes enables a no longer pending dependency to move back to

pending if all hard edges are removed.

Fixes #6604

    • -0
    • +42
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 6 more files in changeset.
Recompute selected component when removing a selector

Previously, once a component was selected, removing a selector would not

change the resolution result, potentially keeping a selection that no

longer applied.

Now upon removal of a selector, the selected component may be updated.

Fixes #6567

    • -5
    • +3
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 5 more files in changeset.
Recompute selected component when removing a selector

Previously, once a component was selected, removing a selector would not

change the resolution result, potentially keeping a selection that no

longer applied.

Now upon removal of a selector, the selected component may be updated.

Fixes #6567

    • -11
    • +8
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 7 more files in changeset.
Import POM files as different variants

This commit implements solution 6 of #4422, by importing POM files

using different variants. By default, a POM file will be imported

as 6 different variants:

- 2 libraries (runtime and compile)

- 4 platforms (runtime and compile, regular and enforced)

This implies that a dependency on a BOM will now be intepreted as

a dependency on a library, whereas a dependency on a BOM expressed

using the `platform(...)` or `enforcedPlatform(...)` methods will

be interpreted as importing the platform component published at

the same coordinates.

This commit doesn't remove optional dependencies for Maven, but

reimplements how the dependencies are shuffled in different variants.

The dependencies found in a dependency management block are no

longer considered optional. Instead, they are properly marked as

constraints. However, they are only visible if using the experimental

flag, **and** using the platform variant.

    • -1
    • +1
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 31 more files in changeset.
Simplify test case for #6403

    • -7
    • +5
    ./VersionConflictResolutionIntegrationTest.groovy
Fix incorrect conflict detection

Whenever 2 selectors agree on the version to use but one of them

is not a "shortcutting" selector, we created a conflict, instead

of checking if they agreed before.

Fixes #6403

    • -0
    • +36
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 2 more files in changeset.
Revert "Support version range merging for '.+' selectors"

Includes additional test changes for coverage added after the initial

commit.

This reverts commit 26da3b84b581a22c7c825495ec1ba4ec45e1febf.

    • -3
    • +3
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 4 more files in changeset.
Fix order dependent resolution when module is evicted

This commit fixes several ordering issues, due to the fact selectors

were still used during resolution even if the corresponding node was

evicted.

Fixes #5530

    • -5
    • +11
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 3 more files 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

    • -6
    • +6
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 29 more files in changeset.
Add test showing dependency ordering issue

    • -0
    • +49
    ./VersionConflictResolutionIntegrationTest.groovy
Fix incorrect conflict resolution when a cycle exists with root component

Whenever the root component was added back through a dependency cycle, we

introduced a conflict, which was solved by the latest module conflict

resolver _unless_ `failOnVersionConflict()` was used. Instead, we shouldn't

even try to resolve a conflict because there's none. This commit fixes the

problem by checking if the root component is already added.

Fixes gradle/gradle-private#1268

    • -0
    • +34
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 1 more file in changeset.
Add coverage for resolution result where some selectors fail

    • -5
    • +41
    ./VersionConflictResolutionIntegrationTest.groovy
Support version range merging for '.+' selectors

Fixes #4180

    • -2
    • +2
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 2 more files in changeset.
Fix test so that it verifies behaviour we want

    • -1
    • +1
    ./VersionConflictResolutionIntegrationTest.groovy
Test resolving version conflicts in transitive dependencies

    • -2
    • +51
    ./VersionConflictResolutionIntegrationTest.groovy
Add test case showing a selection problem

This test case highlights a problem in dependency resolution, when a node was evicted in favor of another node,

but that this other node constraint should go away because it came in through transitivity of a node which itself

has been evicted: since the node is no longer reachable, there's no reason why it should force the selection of

a branch that knows nothing about it.

    • -0
    • +34
    ./VersionConflictResolutionIntegrationTest.groovy
Remove concept of orphan node as it can put the graph into corrupt state

This commit removes the detection of orphan nodes, which triggered the removal of unused selectors. The problem

is that the selector could be used somewhere else in the graph, even if this node doesn't have any incoming edge.

Basically it means that the strategy for "eliminating previous constraints" when a subgraph is elimintated doesn't

work. As a consequence some tests are now marked as `@NotYetImplemented`.

    • -0
    • +2
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 1 more file in changeset.
Add another `@NotYetImplemented` test case

    • -0
    • +34
    ./VersionConflictResolutionIntegrationTest.groovy
Fix assertion error, when restarting happens during conflict resolution...

but component was already selected. This can happen if a node is re-selected between the conflict resolution

has been registered and the moment conflict resolution occurs.

    • -0
    • +70
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 1 more file in changeset.
Make sure we don't create conflicts when the candidate list is empty

It is possible that we're out of candidates now that we filter out versions which are not

selectable from candidates. This happens when we have an orphan node, then a selector chooses

the same version, but cannot be used for short-circuiting (typically, `latest` selector).

    • -0
    • +37
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 3 more files in changeset.
Introduce check on replaced modules before short-circuit selection

When we perform short-circuit selection for a module (where its selected version is `null`), we need to check that

this module actually doesn't participate in module replacements. If it does, we need to fall back on classic conflict

resolution. Otherwise, the following situation might occur:

- `a` is replaced by `b`

- we add `a:1` to the graph. No version is selected for `a`, so we select `a:1`

- we add `b:1` to the graph. No version is selected for `b`, so we select `b:1`

- we end up with both `a` and `b` in the result

Instead, we now follow this process:

- `a` is replaced by `b`

- we add `a:1` to the graph. No version is selected for `a`, but `a` participates in replacements. We don't short-circuit,

but in the end we select `a:1`

- we add `b:1` to the graph. No version is selected for `b`, but `b` participates in replacements. We fall back to conflict

resolution, which sees that `a` needs to be replaced by `b`.

- only `b:1` ends up in the result

    • -2
    • +0
    ./VersionConflictResolutionIntegrationTest.groovy
  1. … 5 more files in changeset.