DependencyConstraintsAndResolutionStrategiesIntegrationTest.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.

    • -188
    • +0
    ./DependencyConstraintsAndResolutionStrategiesIntegrationTest.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
    • +1
    ./DependencyConstraintsAndResolutionStrategiesIntegrationTest.groovy
  1. … 43 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)`.

    • -5
    • +5
    ./DependencyConstraintsAndResolutionStrategiesIntegrationTest.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.

    • -4
    • +4
    ./DependencyConstraintsAndResolutionStrategiesIntegrationTest.groovy
  1. … 50 more files in changeset.
Make `failOnVersionConflict` non-fatal on demand

Before this commit, `failOnVersionConflict()` was triggering a failure

during dependency resolution as soon as a conflict was discovered. This

commit changes this so that conflicts are resolved as usual, but a

validation step triggers an error after resolution if a conflict is found.

The `ResolutionResult` API has been updated so that a consumer can

set an alternate error handler, in which case whenever the resolution is

triggered, we can intercept the error and do something. In case of the

dependency insight report, this now allows not failing the build if

there's a resolution error due to the fail on conflict flag, but instead

show a resolved graph with a warning that a conflict happened.

    • -2
    • +2
    ./DependencyConstraintsAndResolutionStrategiesIntegrationTest.groovy
  1. … 23 more files in changeset.
Separate Dependency Constraint and Dependency declarations (#4255)

The interfaces for declaring these two different things were

coupled in the initial implementation - to reuse all functionality

based on the Dependency interface directly. This interface is used

internally to pass dependency declarations through the resolution

process. However, this is only due to remembering the first

level dependencies for the "old" results API

(Configuration.resolvedConfiguration()).

These implementation specifics should not bleed into the API.

A dependency declaration defines a *requirement*:

I require module/project X

A dependency constraint defines a *constraint*:

If I must use X, I can only work with versions matching the constraint

Only if we look at external dependencies, constraints and external dependencies

share the ability to declare a *version constraint*. Therefore, both now

extend ModuleVersionSelector.

Now, dependency constraints are removed as "first level dependencies"

from the result. This is fine as the dependency itself is still in the

result graph - when there is a constraint, there is always at least one other

edge.

    • -3
    • +3
    ./DependencyConstraintsAndResolutionStrategiesIntegrationTest.groovy
  1. … 33 more files in changeset.
Add test for combining dependency constraints with other features

These test cases document the current behavior when dependency

constraints are combined with other dependency management mechanisms.

They do not represent recommended use cases.

If dependency constraints and component metadata rules are used, using

other mechanisms should not be required.

Fixes #3656

    • -0
    • +187
    ./DependencyConstraintsAndResolutionStrategiesIntegrationTest.groovy