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

    • -5
    • +1
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 38 more files in changeset.
Remove special casing of pure ivy in resolve tests

    • -5
    • +1
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 9 more files in changeset.
Remove special casing of pure ivy in resolve tests

    • -5
    • +1
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 11 more files in changeset.
Use ivy derivation rules in resolve tests

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

    • -5
    • +7
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 12 more files in changeset.
Use ivy derivation rules in resolve tests

This allows us to get rid of some special casing in tests that

do not specifically test ivy-only behavior. This tests that common

variant aware dependency management scenarios work for ivy if used

in the recommended way.

    • -5
    • +7
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 12 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -5
    • +4
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 15 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -5
    • +6
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 18 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -5
    • +7
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 20 more files in changeset.
Allow variant matching opt-in for ivy through component metadata rules

    • -5
    • +7
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 20 more files in changeset.
Merge branch 'master' into feature/JLL/depricate_http_download_dependencies

* master: (724 commits)

Highlight Gradle Module Metadata support as feature of the release

Add note about configurations deprecations

Increase DaemonErrorFeedbackCrossVersionSpec timeout

Recognize contributor

recognize contributor

Publish 5.6-20190819230034+0000

Remove no longer necessary instant execution codecs for `EnumSet` and `EnumMap`

Improve instant execution support for Java serialization

Polish `BeanPropertyReader.kt`

Polish `BeanCodecTest`

Polish `Codec.kt`

Introduce `SerializableWriteObjectCodec`

Polish `ClosureCodec`

Prepare `BindingsBackedCodec` to accept multiple encodings for the same binding

Simplify `BindingsBackedCodec` usage

Polish `BindingsBackedCodec`

Polish `LoadDirectoryTest`

Remove unused `SerializationFixture` class

Use latest Scan plugin 2.4.1-rc-1

Move Play plugins retirement to 7.0 for now

...

    • -22
    • +15
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 21 more files in changeset.
Adjust tests and samples to new metadata sources defaults

    • -22
    • +15
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 95 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -22
    • +15
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -22
    • +15
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

    • -22
    • +15
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 32 more files in changeset.
Revert "Revert "Merge remote-tracking branch 'origin/sg/merges/pr-9419'""

This reverts commit 0625bc7420e55e87730673231af6ad45dd04f47a.

    • -4
    • +4
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 90 more files in changeset.
Revert "Revert "Merge remote-tracking branch 'origin/sg/merges/pr-9419'""

This reverts commit 0625bc7420e55e87730673231af6ad45dd04f47a.

    • -4
    • +4
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 90 more files in changeset.
Revert "Merge remote-tracking branch 'origin/sg/merges/pr-9419'"

This reverts commit 2f79026f5e127a8175e25844522237615b19ed52 because of a performance regression,

reversing changes made to 7f1e66079ce629ecde3e09e549e9796ab85761dc.

    • -4
    • +4
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 90 more files in changeset.
Cleanup some unnessasary changes after depricate http changes

Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>

    • -2
    • +0
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 10 more files in changeset.
Fix integration tests failing due to new dperication

Signed-off-by: Jonathan Leitschuh <Jonathan.Leitschuh@gmail.com>

    • -4
    • +6
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 10 more files in changeset.
Introduce a `JAVA_API_JARS` usage

This commit introduces a new `JAVA_API_JARS` usage, mirror

to the `JAVA_RUNTIME_JARS` usage. This is both for consistency,

and to make sure that the `JAVA_API` and `JAVA_RUNTIME` usages

are limited to cases where the consumer doesn't care, or when

a producer doesn't have a more specific usage to provide.

This is, for example, the case for Java platforms. It's worth

noting than in case a producer mixes both "generic" usages

and "specific" usages, selection is likely to produce unexpected

results, because of disambiguation rules.

The Java disambiguation rule has been simplified and now

supports more cases.

    • -0
    • +1
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 37 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
    ./AbstractModuleDependencyResolveTest.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.

    • -2
    • +1
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 50 more files in changeset.
Simplify test fixtures for alignment tests

    • -1
    • +1
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 1 more file in changeset.
Add initial support component metadata supplier caching

This commit adds the infrastructure for caching of component metadata rules.

For now, the only kind of rule we can cache are the component metadata supplier

rules, which are used during dynamic version selection, but the executor

infrastructure can be reused to cache more kinds of rules.

The implementation relies on the principal that a "rule" can be safely cached if:

- the rule has no side effect, and uses the "class-based pattern"

- the implementation of the rule didn't change

- the inputs of the rule didn't change

For this, we introduce a new persistent cache (hence cross-build) with an in-memory

facing cache, that allows us to avoid the execution of a rule if the result is

already in the cache. The implementation makes use of _snapshotting_ to capture the

state of the inputs of a rule, which consists of the implementation of the rule and

its potential parameters. It's worth noting that at this stage we do not consider

the services the rule can use, it's going to be done in a subsequent commit.

This worked required a clarification of what an rule cares about (the result) in

opposition to what the user is faced with. For example, a component metadata supplier

rule output is a `ComponentMetadata`, but what we offer to the user, to build that

metadata, is a `ComponentMetadataSupplierDetails` instance. Similarly, component

metadata rules would have different kind of output and what the user manipulates.

The cache works with a primary key (for the first implemented cache, the key is the

module version identifier) and will invalidate the results based on the cache policy

(should refresh modules).

The persistent cache uses the snapshot as the key in the store. In theory, should we

consider that we have a nearly perfect hash function, we could instead use the hash

of the snapshot as the key. Measurements would have to be made to check if it's worth

implementing.

    • -1
    • +5
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 46 more files in changeset.
Add initial support component metadata supplier caching

This commit adds the infrastructure for caching of component metadata rules.

For now, the only kind of rule we can cache are the component metadata supplier

rules, which are used during dynamic version selection, but the executor

infrastructure can be reused to cache more kinds of rules.

The implementation relies on the principal that a "rule" can be safely cached if:

- the rule has no side effect, and uses the "class-based pattern"

- the implementation of the rule didn't change

- the inputs of the rule didn't change

For this, we introduce a new persistent cache (hence cross-build) with an in-memory

facing cache, that allows us to avoid the execution of a rule if the result is

already in the cache. The implementation makes use of _snapshotting_ to capture the

state of the inputs of a rule, which consists of the implementation of the rule and

its potential parameters. It's worth noting that at this stage we do not consider

the services the rule can use, it's going to be done in a subsequent commit.

This worked required a clarification of what an rule cares about (the result) in

opposition to what the user is faced with. For example, a component metadata supplier

rule output is a `ComponentMetadata`, but what we offer to the user, to build that

metadata, is a `ComponentMetadataSupplierDetails` instance. Similarly, component

metadata rules would have different kind of output and what the user manipulates.

The cache works with a primary key (for the first implemented cache, the key is the

module version identifier) and will invalidate the results based on the cache policy

(should refresh modules).

The persistent cache uses the snapshot as the key in the store. In theory, should we

consider that we have a nearly perfect hash function, we could instead use the hash

of the snapshot as the key. Measurements would have to be made to check if it's worth

implementing.

    • -1
    • +5
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 46 more files in changeset.
Add support for component metadata suppliers for Maven repositories

This implements feature parity between Ivy and Maven repositories with regards to

component metadata suppliers. Before, only Ivy repositories could benefit from

user provided component metadata suppliers. Now, both Maven and Ivy repositories

support this. The test that was Ivy specific has been migrated to the new test

fixtures, allowing us to check both Maven and Ivy in a single test class.

    • -0
    • +12
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 18 more files in changeset.
Add support for version lister on Ivy repositories

This commit introduces the concept of custom version lister. Whenever

a dynamic version of a module is requested, Gradle has to perform a

lookup on a remote repository to list the available versions of this

component. With this change, it is now possible for a build author to

provide a custom version lister. This can be used to solve different

problems:

- it becomes possible to have a single remote resources that lists all

versions of all known module, for example

- avoid hitting a remote repository if we know a module will never be

found there

Note that for the latter, if the version is _fixed_, the version lister

will never be called so we will reach the remote repository in any case.

For the purpose, an interface, `MetadataSupplierAware` has been extracted

and is for now only used by Ivy repositories, because the latter was the

only one providing component metadata suppliers.

With this change it will become possible for Maven repositories to

support that too.

It's worth noting that the goal of this separation of concerns is to make

it possible for a user to either supply a version lister, a component

metadata supplier, or both. And if using both, a shared cache can be used

to avoid reaching a repository multiple times. This means that in theory

it should be possible to perform a single network request to both list

the versions of a component **and** get the component metadata necessary

to perform the selection of the component.

This commit does _not_ declaring the attributes of a component yet.

    • -0
    • +12
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 21 more files in changeset.
Transform FeaturePreviewsFixture to use the new API

Replaces injecting a property in the gradle.properties with injecting

the gradle.enableFeaturePreview in settings.gradle

    • -2
    • +2
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 16 more files in changeset.
Turn experimental option into gradle metadata option

Signed-off-by: Jendrik Johannes <jendrik@gradle.com>

    • -1
    • +1
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 18 more files in changeset.
Rename 'experimental features' to 'feature previews'

The idea behind this is that we have a set of feature previews rather

than one cryptic experimental flag.

A feature preview collects a set of related functionality (e.g.

everything related to gradle metadata) that changes existing behavior

and thus could potentially break existing builds. The preview options

will be removed with the next major release (currently 5.0) and the new

behaviour will then become the default.

Signed-off-by: Jendrik Johannes <jendrik@gradle.com>

    • -3
    • +3
    ./AbstractModuleDependencyResolveTest.groovy
  1. … 45 more files in changeset.