Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Provide in-memory caching for dependency caches

Instead of using a separate `InMemoryCachedModuleComponentRepository`

for in-memory caching of resolution from remote repositories, the

filesystem-backed cache implementations now each have a build-scoped

in-memory cache as well.

This provides more consistent caching behaviour, since any cache-expiry

logic is shared between in-memory and filesystem caches.

For file-backed repositories, we don't use the filesystem-backed cache,

so we continue to use `InMemoryCachedModuleComponentRepository` for

in-memory caching of resolved modules.

Note that this is only a partial fix, as it does not address the

incorrect caching of maven snapshot modules. This is due to the id-based

caching of resolved artifacts, and the fact that different maven

snapshot instances do not have a different unique identifier.

  1. … 7 more files in changeset.
Serialize dependency reasons

This commit adds support for serializing dependency (constraint) reasons to disk, both through component

metadata binary serialization and in module metadata.

Signed-off-by: Cedric Champeau <>

  1. … 17 more files in changeset.
Add support for showing the resolved variant and its attributes in `ResolvedComponentResult`

This commit adds a `ResolvedNamedVariantResult getVariant()` method on `ResolvedComponentResult`,

which gives access to the resolved variant details. In practice, the details are currently limited


- the name of the variant

- the attributes attached to this variant

The attributes are desugared: if the original variant had strongly-typed attributes, what we get

by the result of this call is an attribute container where all attributes are of type `String`.

As a consequence, it should only be used for diagnostics.

The `ResolveTestFixture` has been adjusted so that we can now (optionally) check the selected

variant and its attributes. One test has been adjusted to check the variant.

Signed-off-by: Cedric Champeau <>

  1. … 24 more files in changeset.
Create all mutable Ivy module resolve metadata through factory

This will simplify the injection of services through the factory, when we will need the immutable

attributes factory to be pushed to resolve metadata.

  1. … 25 more files in changeset.
Instantiate mutable Maven metadata through dependency injecting instantiator

This commit prepares the ability to inject services into mutable Maven metadata. This will be

required to inject the immutable attributes factory, as well as the object instantiator and

possibly other services to the immutable Maven resolve metadata. This commit reduces the

number of constructors of `DefaultMavenModuleResolveMetadata`, to make it easier to maintain.

Some tests still create mutable module resolve metadata directly. Ideally, they should also

use the factory.

  1. … 18 more files in changeset.
Rework `DefaultMutableIvyModuleResolveMetadata` constructors for consistency

Introduce constants where it makes sense and use consistent order of parameters.

  1. … 5 more files in changeset.
Merge `MutableModuleComponentResolveMetadata` and `MutableComponentVariantResolveMetadata` together.

There was a point where all mutable module resolve metadata weren't "variant aware", but that's not the case

anymore, so having two separate interfaces adds complexity we don't need.

  1. … 13 more files in changeset.
Make sure that published component attributes can also be mutated

This commit adds support for serialization of component level attributes. Before, the module metadata descriptor

could contain attributes, but since we never used them, apart from the hard-coded `status` attribute, there was

no need to serialize them in binary format. Now, it is possible for a consumer to overwrite component attributes,

including custom attributes. This makes necessary for serializing this information.

However, this commit does NOT add support for publishing component attributes: at this point, while there's a way

to _consume_ attributes, there's no way to _publish_ them.

  1. … 10 more files in changeset.
Fix dependency constraints not being serialized

This commit fixes the fact that dependency constraints weren't serialized. This meant that if dependency metadata was fetched

from cache instead of being retrieved from parsed files, the resolution would have been different. The test makes sure that

we read and write them properly.

Don't use a strongly type attribute for usage

For "foreign" metadata sources the only expected types are `Attribute<Boolean>`

and `Attribute<String>`. The `String` version is coerced at runtime to more

complex attribute types like `Usage`.

  1. … 5 more files in changeset.
Push dependencies down to Ivy/Maven subtypes of ComponentResolveMetadata

  1. … 15 more files in changeset.
Renamed `DefaultDependencyMetadata` -> `ExternalDependencyDescriptor`

This type now represents the external representation of a dependency, not the

internal `DependencyMetadata`. Also renamed and polished Ivy/Maven subtypes.

  1. … 34 more files in changeset.
Detangle `DefaultDependencyMetadata` from `ModuleDependencyMetadata`

- `DefaultDependencyMetadata` no longer pretends to implement `ModuleDependencyMetadata`

- `ConfigurationDependencyMetadataWrapper` does not require a `ModuleDependencyMetadata` delegate

  1. … 12 more files in changeset.
Don't use Ivy abstractions to compose MavenDependencyMetadata

The Ivy descriptor format has pervaded our design for too long.

Ivy begone!

  1. … 9 more files in changeset.
Make `DefaultExclude.artifacts` nullable

Use `null` value for exclude that doesn't exclude artifacts

This is likely more efficient that the existing wildcard match,

and more consistent with other wildcard matches.

  1. … 10 more files in changeset.
Make `Exclude.patternMatcher` nullable

Use a null value for the default exclude rule pattern matching.

Only use a concrete value when defined in an Ivy descriptor.

  1. … 4 more files in changeset.
Extracted `ExcludeMetadata` out of `Exclude`

`Exclude` represents an Ivy representation of an exclude rule, which

may apply to different configurations. In Gradle, an Exclude is attached to a single

configuration or a single dependency, so `Exclude.getConfigurations()` didn't make


With this change, `ExcludeMetadata` represents the portion of an exclude that actually

matters when resolving, pushing `Exclude` down to Ivy/Maven specific classes.

  1. … 38 more files in changeset.
Move `DependencyMetadata.force` to `LocalOriginDependencyMetadata`

We only honour the 'force' attribute for first-level dependencies, so it is

only valid for dependencies described in the build script. (We never

supported the 'force' attribute when defined in Ivy.xml).

  1. … 10 more files in changeset.
Remove the extraneous `DependencyMetadata.excludes` property

- Pushed `getExcludes` down to Ivy/Maven dependency metadata, and renamed

to `getAllExcludes`

- Renamed `getFilteredExcludes` to `getExcludes`

  1. … 18 more files in changeset.
Remove ability update Excludes on metadata

This functionality wasn't required, and was adding complexity.

  1. … 6 more files in changeset.
Use `ImmutableList` for variant excludes

  1. … 3 more files in changeset.
Use ExcludeRuleConverter for creating exclude rule instances

  1. … 4 more files in changeset.
Cleanup exclude parsing in ModuleMetadataSerializer

Use ModuleIdentifierFactory when creating ExcludeRules for module metadata

  1. … 6 more files in changeset.
Write structured excludes to module metadata

Instead of an encoded "$group:$module" string keep the parts

separate in module metadata and in internal representations

of variant dependency excludes.

  1. … 12 more files in changeset.
Ensure that exclude rules are correctly cached for module metadata

  1. … 1 more file in changeset.
Support consumption of dependency excludes from Gradle module metadata

- Support excludes on `ComponentVariant.Dependency`.

- Parse dependency excludes from module metadata and populate ResolveMetadata.

- Generate correct module metadata when exclusions are defined for a test module.

- Enable existing exclude tests for Gradle metadata.

  1. … 15 more files in changeset.
Add support for resolving strict dependencies from an Ivy repository

So far strict dependencies were only supported when resolving from a Maven repository. This commit adds

the necessary infrastructure to make it work on Ivy repositories too. It's worth noting that similarly

to Maven, as soon as Gradle metadata is used, variants from the original Ivy metadata file are "ignored",

and it's a lossy conversion.

This commit is a "make it work". There's still missing test coverage, and there's redundant code due

to the replication of what has been setup for the Maven repositories. Subsequent commits will fix that.

  1. … 41 more files in changeset.
Delegate serialization of ModuleComponentSelector

  1. … 4 more files in changeset.
Back ModuleDependencyMetadata implementations with ModuleComponentSelector

Replace the backing ModuleVersionSelector with a ModuleComponentSelector for:

- IvyBackedMetadata

- MavenBackedMetadata

- GradleBackedMetadata

Converted a few more uses of ModuleVersionSelector -> ModuleComponentSelector

  1. … 19 more files in changeset.