Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Serialize `Transform.fromAttributes` to the configuration cache

    • -5
    • +5
    ./resolve/transform/DisambiguateArtifactTransformIntegrationTest.groovy
  1. … 6 more files in changeset.
DSL tweaks

    • -2
    • +2
    ./resolve/DependencySubstitutionRulesIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix merge problem.

    • -1
    • +1
    ./resolve/maven/MavenVersionRangeResolveIntegrationTest.groovy
Remove @ToBeFixedForInstantExecution on DefaultArtifactCacheLockingManagerIntegrationTest

by using :help in lieu of :tasks

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -6
    • +3
    ./resolve/caching/DefaultArtifactCacheLockingManagerIntegrationTest.groovy
Remove @ToBeFixedForInstantExecution on ArtifactTransformCachingIntegrationTest

by using :help in lieu of :tasks

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -2
    • +1
    ./resolve/transform/ArtifactTransformCachingIntegrationTest.groovy
Integrate review suggestions

Issue #13050

    • -4
    • +2
    ./resolve/maven/MavenDynamicResolveIntegrationTest.groovy
  1. … 5 more files in changeset.
Update behaviour for exclude upper bound in range

The upper bound of a version range, when it is an exclusion, now acts as

a smart prefix. Versions that were excluded before remain excluded. In

addition, versions that start with the upper bound are also excluded.

This resolves the unexpected case where 2.0-dev1 is included when the

upper bound is 2.0[.

Fixes #13050

    • -0
    • +46
    ./resolve/maven/MavenVersionRangeResolveIntegrationTest.groovy
  1. … 7 more files in changeset.
Fix test for instant execution

    • -1
    • +1
    ./resolve/RepositoryContentFilteringIntegrationTest.groovy
Change `AbstractIntegrationSpec` to fail when a test runs a build that fails with more than one exception and does not verify the number of exceptions in the failure using `assertHasFailures()`.

This is to avoid additional exceptions unintentionally being introduced, for example when a failure starts being thrown because of configuration cache problems alongside the expected failure.

    • -0
    • +7
    ./resolve/DependencyUnresolvedModuleIntegrationTest.groovy
    • -0
    • +1
    ./resolve/ProjectDependencyResolveIntegrationTest.groovy
    • -0
    • +7
    ./resolve/PublishedRichVersionConstraintsIntegrationTest.groovy
    • -0
    • +1
    ./resolve/api/ConfigurationMutationIntegrationTest.groovy
    • -0
    • +4
    ./resolve/attributes/ComponentAttributesDynamicVersionIntegrationTest.groovy
    • -0
    • +5
    ./resolve/attributes/DependenciesAttributesIntegrationTest.groovy
    • -2
    • +10
    ./resolve/attributes/MultipleVariantSelectionIntegrationTest.groovy
    • -0
    • +2
    ./resolve/bundling/JavaBundlingResolveIntegrationTest.groovy
    • -1
    • +3
    ./resolve/caching/CachedMissingModulesIntegrationTest.groovy
    • -0
    • +2
    ./resolve/capabilities/CapabilitiesConflictResolutionIntegrationTest.groovy
    • -0
    • +6
    ./resolve/capabilities/CapabilitiesUseCasesIntegrationTest.groovy
    • -0
    • +4
    ./resolve/capabilities/PublishedCapabilitiesIntegrationTest.groovy
    • -0
    • +2
    ./resolve/constraints/DependencyConstraintsAndResolutionStrategiesIntegrationTest.groovy
  1. … 67 more files in changeset.
Make classifier substitution available to `eachDependency`

Classifier (and more generally artifact substitution) is now possible

using the legacy `eachDependency` API. While we shouldn't encourage

use of this if `dependencySubstitutions` can be used, it's important

to be on par.

    • -1
    • +9
    ./resolve/DependencySubstitutionRulesIntegrationTest.groovy
  1. … 9 more files in changeset.
Avoid resolving a repository url eagerly

Given we only need the repository name for error messages, there is

no need to resolve it directly (which also resolves the url of the

repository which may be a provider).

Fixes #13152

    • -4
    • +22
    ./resolve/RepositoryContentFilteringIntegrationTest.groovy
  1. … 5 more files in changeset.
Add support for "classifier" dependency substitution

This commit adds a DSL to make substitutions of dependencies which use

classifiers (or in general _artifact notations_) easier. In particular,

it avoids the use of component metadata rules, which, while being the

_right_ solution, are a bit cumbersome and need to be implemented in

a plugin.

    • -0
    • +123
    ./resolve/DependencySubstitutionRulesIntegrationTest.groovy
  1. … 34 more files in changeset.
Remove `@ToBeFixedForInstantExecution(skip = FLAKY)` from `ArtifactTransformCachingIntegrationTest`

    • -6
    • +0
    ./resolve/transform/ArtifactTransformCachingIntegrationTest.groovy
Fix wiring of feature preview in version comparator

The version comparator can be used before settings are evaluated, for

settings plugin resolution.

This means that we need to reconfigure it after settings have been

evaluated, so that the feature preview opt-in works.

Issue #13050

    • -4
    • +26
    ./resolve/maven/MavenDynamicResolveIntegrationTest.groovy
  1. … 3 more files in changeset.
Inject FeaturePreviews in DefaultVersionComparator

This will enable to select which StaticVersionComparator to use based on

feature preview activation.

As a consequence, the VersionComparator becomes build scoped and has to

be injected instead of being instantiated in different places.

Issue #13050

    • -1
    • +2
    ./resolve/strict/StrictVersionConstraintsFeatureInteractionIntegrationTest.groovy
  1. … 26 more files in changeset.
Use different source hash for absent metadata

Previously, a constant was used, but that meant that all modules missing

metadata would have the same source hash.

With this change, the module component identifier is used, so that two

different modules with no metadata do not have the same hash.

Fixes #13028

    • -0
    • +50
    ./resolve/rules/ComponentMetadataRulesCachingIntegrationTest.groovy
  1. … 2 more files in changeset.
Don't write in RO dependency cache when parent POM is missing

This commit works around a bug whenever the read-only dependency cache

used to contain a parent POM, but it has been cleaned up in between

(for example via the seeding build).

In this case, if a "consumer" build uses the read-only cache and

resolves a dependency which has the same parent POM, it will attempt

to write in the read-only dependency cache even if it shouldn't.

The ideal fix would be to avoid tweaking the failsafe cache, but it

appears that some read operations _may_ trigger a write operation

in between (as a cleanup side effect). This commit therefore makes

sure that we don't even attempt to call a write operation in this

case.

Fixes #12996

    • -0
    • +60
    ./resolve/rocache/ParentPomsReadOnlyCacheDependencyResolutionTest.groovy
  1. … 2 more files in changeset.
Fix metadata realization

The "dependency filter" in module metadata is a performance optimization,

which allows filtering out some particular kinds of dependencies _without

having to duplicate the collection_ which is particularly expensive.

However, when we call the builder to mutate metadata, we shouldn't use

the current value of the builder as the initial value, because it causes

the mutated state to be in a wrong state.

This fixes a failing test in "force realize" case.

    • -2
    • +0
    ./resolve/MultiProjectDerivationStrategyIntegTest.groovy
  1. … 1 more file in changeset.
Ignore failure for now

    • -0
    • +2
    ./resolve/MultiProjectDerivationStrategyIntegTest.groovy
Account for null version constraint on selector

This is the case for project selectors.

Fixes #12997

    • -1
    • +39
    ./resolve/reproducibility/FailOnDynamicVersionsResolveIntegrationTest.groovy
  1. … 2 more files in changeset.
Mark test as to be fixed for instant execution

    • -0
    • +2
    ./resolve/DependencyHandlerProviderIntegrationTest.groovy
Use more idiomatic test constructs

    • -49
    • +106
    ./resolve/DependencyHandlerProviderIntegrationTest.groovy
  1. … 2 more files in changeset.
Consider the derivation strategy when requesting component metadata

Gradle has a single, build scoped cache for dependency metadata. It's

using a build cache scope because component metadata is quite expensive

to read and process. However, component metadata _may_ be different

based on the plugins applied on a project. For example, Java projects

apply what we call a "Java derivation strategy", which is capable

of transforming regular POM files into so-called "platforms" but

more importantly, they are what map the different Maven scopes to

actual "variants" in variant-aware dependency management.

The problem is that it's not a requirement that all projects are

Java projects. It is possible to have native subprojects, or projects

which do _not_ apply the Java base plugin. While it's in general an

error to have a project which wants to perform "Java dependency

resolution" not to apply the Java derivation strategy, there are

consequences in not doing so. In particular, Gradle becomes order

dependent: if a subproject which does not apply the derivation

strategy resolves a module first, then subsequent resolutions for

projects which _do_ apply the derivation strategy would get wrong

metadata.

To avoid this, this commit makes sure that when we consume module

metadata, we actually use the derivation strategy as part of the

processed metadata cache key.

This does _not_ fix the fact that the consumers _should have_ applied

the derivation strategy and will make realizing this harder, but it

_does_ fix the inconsistency in resolution, which is probably a

much bigger issue (for caching and reproducibility).

    • -0
    • +93
    ./resolve/MultiProjectDerivationStrategyIntegTest.groovy
  1. … 12 more files in changeset.
Fix `ResolvedDependencyResult#getResolvedVariant` returning `null`

A resolved dependency should always have a resolved variant. It was

possible to get `null` in case the actual component being resolved

was from a different component, for example in the case of dependency

subsitution.

Fixes #12643

    • -29
    • +72
    ./resolve/api/ResolutionResultApiIntegrationTest.groovy
  1. … 1 more file in changeset.
Add required `forUseAtConfigurationTime()` to `ConfigurationDefaultsIntegrationTest`

    • -1
    • +1
    ./resolve/api/ConfigurationDefaultsIntegrationTest.groovy
Fix binary store exception due to invalid constraint edge

It was possible to have a constraint remain in the graph without a

matching hard dependency.

When that happens, the constraint edge ends up pointing to a node that

is not selected and thus causes an exception when the binary store is

read from disk.

Fixes #12900

    • -0
    • +80
    ./resolve/PublishedDependencyConstraintsIntegrationTest.groovy
  1. … 1 more file in changeset.
Apply system property read detection to Groovy DSL scripts.

    • -1
    • +1
    ./resolve/api/ConfigurationDefaultsIntegrationTest.groovy
  1. … 36 more files in changeset.
Apply the Java derivation strategy to the Java Platform plugin

This commit makes sure that the Java Platform plugin also applies the

Java derivation strategy, as it, as it names indicates, also belongs

to the Java ecosystem. Not doing so triggers some weird ordering issues

if another project, which is a Java library, tries to resolve the same

dependencies as the Java platform, but after the platform has resolved

them.

Because of component metadata caching, the first project to resolve

a dependency will be the "source of truth" for dependency metadata for

the module for the whole build. It means that if it was a Java library,

then the derivation strategy was applied and the project could resolve

everything properly. However, if the first project to trigger resolution

of a module was a Java Platform, then we would cache component metadata

_without_ derivation. This means, in particular, that platforms wouldn't

be derived for external Maven modules.

This explains why in #12728, order of execution of tasks matters: if

the subproject was resolved _first_ (gradle sub:compileJava resolve)

then everything was fine, but if the platform was resolved first, then

the rest of the build would fail.

The fix is to apply the derivation strategy to the Java platform plugin

too. However, in an ideal world, we should refactor the Java plugins so

that they consist of several layers:

- a "schema" layer, configuring the ecosystem schema, the derivation strategy, ...

- a "base" layer, consisting of what the Java Base plugin does today

- a "platform", directly on top of "schema"

- an application, and a "library", on top of "base"

Fixes #12728

    • -0
    • +77
    ./resolve/platforms/JavaPlatformEcosystemIntegrationTest.groovy
  1. … 1 more file in changeset.
Fixed order for entires in classpath manifest files

    • -2
    • +2
    ./resolve/api/DependencyHandlerApiResolveIntegrationTest.groovy
  1. … 1 more file in changeset.
Fix invalid caching of exclusion

When the exclusion set changes but does not impact the current node,

the engine still need to ensure that nodes lower down the graph are not

impacted either.

Fixes #12751

    • -1
    • +94
    ./resolve/ModuleDependencyExcludeResolveIntegrationTest.groovy
  1. … 2 more files in changeset.