MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Let dependency-management tests not use deprecated configurations

    • -8
    • +8
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 27 more files in changeset.
Let dependency-management tests not use deprecated configurations

    • -8
    • +8
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 27 more files in changeset.
Let dependency-management tests not use deprecated configurations

    • -8
    • +8
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 27 more files in changeset.
Let dependency-management tests not use deprecated configurations

    • -8
    • +8
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 27 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
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 43 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.

    • -9
    • +9
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 50 more files in changeset.
Use attribute matching for selection whenever target component has variants

Previously, for a dependency declared in a POM or Ivy descriptor file, we

would _not_ use attribute matching to choose a variant from a local Gradle

project. Since there's no way a POM or Ivy file could reference a Gradle

project directly, this could only occur if the dependency was substituted with

a project dependency.

This is a slight breaking change to the (still) incubating dependency substitution

behaviour, but it makes the behaviour more consistent with regular project

dependencies.

- If the target project configurations do not declare attributes, then the behaviour

is unchanged.

- If the target project configurations have attributes (ie apply the 'java' plugin')

then attribute matching will be used to choose the appropriate target configuration.

This means that the 'api' variant will be selected when resolving a 'compileClasspath'

and the 'implementation' variant will be selected when resolving a 'runtimeClasspath'.

    • -8
    • +8
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 1 more file in changeset.
Changed resolution of dependencies of Maven modules to attempt to select the fewest configurations of the target module as possible to give the correct result. Previously, every dependency of a Maven module would select the `compile`, `runtime` and `master` configurations of the target. Now, it will usually select only the `compile` configuration of the target when resolving the Maven module's `compile` configuration, and the `runtime` configuration of the target when resolving any others.

This changes means there are far fewer nodes and edges in the dependency graph in the case of resolving external dependencies from Maven repositories, which has an impact on resolution time. There is a breaking change here, in that the 'resolved configuration' resolution result will contain fewer configuration nodes. It will still contain the same modules and artifacts, in the same order.

This change also changes the way that configurations are selected when a Maven module consumes an Ivy module or a Gradle project (through project substitution). Previously, _all_ of the public configurations of the target would be selected when _any_ of the `compile`, `runtime` or `master` configuration were not defined by the target. Given that the core plugins do not define a `master` configuration, this means that all public configurations, such as custom configurations defined in a build script, would be selected and their dependencies and artifacts included in the result. Now, when `compile` or `runtime` are missing, the `default` configuration is selected instead. A missing or empty `master` configuration is ignored.

    • -3
    • +3
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 13 more files in changeset.
Added some more int test coverage for interaction between maven scopes and ivy module configurations and project configurations, when various kinds of dependency substitutions are used.

    • -0
    • +234
    ./MavenScopesAndProjectDependencySubstitutionIntegrationTest.groovy
  1. … 4 more files in changeset.