MixedMavenAndIvyModulesIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Adjust test fixtures and test to ivy behavior changes

    • -6
    • +6
    ./MixedMavenAndIvyModulesIntegrationTest.groovy
  1. … 38 more files in changeset.
Fixes

    • -6
    • +6
    ./MixedMavenAndIvyModulesIntegrationTest.groovy
  1. … 29 more files in changeset.
Fixes

    • -6
    • +6
    ./MixedMavenAndIvyModulesIntegrationTest.groovy
  1. … 19 more files in changeset.
Fixes

    • -6
    • +6
    ./MixedMavenAndIvyModulesIntegrationTest.groovy
  1. … 31 more files in changeset.
Proper propagation of flag when modifying metadata

The `ConfigurationBoundExternalDependencyMetadata` was not properly

propagating the `alwaysUseAttributeMatching` state when the metadata was

modified.

This caused legacy Maven / Ivy interop to kick in, as happened before Maven

was fully moved to variant aware dependency management. One test needed

to be modified, which in reality should have been changed at the 5.0

release.

Fixes #8586

    • -8
    • +8
    ./MixedMavenAndIvyModulesIntegrationTest.groovy
  1. … 1 more file 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
    ./MixedMavenAndIvyModulesIntegrationTest.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.

    • -38
    • +28
    ./MixedMavenAndIvyModulesIntegrationTest.groovy
  1. … 50 more files 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.

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

    • -3
    • +143
    ./MixedMavenAndIvyModulesIntegrationTest.groovy
  1. … 4 more files in changeset.
Added some int test coverage for interaction between Maven scopes and Ivy configurations.

    • -0
    • +206
    ./MixedMavenAndIvyModulesIntegrationTest.groovy
  1. … 27 more files in changeset.