Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename id accessors for consistency

Use `ComponentIdentifier getId()`

Use `ModuleVersionIdentifier getModuleVersionId()`

  1. … 65 more files in changeset.
Rename `CapabilitiesDescriptor` to `Capabilities`

... and `getCapababilitiesMetadata()` to `getCapabilities()` for consistency.

  1. … 36 more files in changeset.
Add support for capabilities in module metadata

This commit adds support for capabilities in module metadata. Capabilities are found under variants,

and we make sure to serialize the capabililities to their binary form too. However, there's still no

way to publish the capabilities, nor test fixtures to simulate published capabilities.

  1. … 9 more files in changeset.
Revert the initial implementation of capabilities

Revert "Remove the `Preference` inner class"

Revert "Add test case showing limitation of the current implementation of capabilities"

Revert "Report error whenever two modules in the graph disagree on a preference"

Revert "Support capabilities with project dependencies"

Revert "Consume capabilities from external modules"

Revert "Handle case of conflicting resolution in case multiple capabilities are found"

Revert "Make sure that conflict resolution on version still kicks in"

Revert "Wire capabilities handling into conflict resolution"

Revert "Introduce `CapabilitiesHandlerInternal`"

Revert "Validate module notations in capabilities"

Revert "Introduce the concept of "capabilities""

This reverts commit a6248b2c4e7a810051112fc2169c97d341b9f007.

This reverts commit 76e88732f403d1b295c879bdee0b0a92887e4173.

This reverts commit d9dbe0f6d909604d31857504133440f92996d3f3.

This reverts commit ac3ffa467dd73314b4526b79df3cedf6db4e6c13.

This reverts commit 97f523cd78cdca3819a8a6d65d33b72f8b972646.

This reverts commit d4c02e3f13340ce2d6114cd17f741ac51fee7796.

This reverts commit 4d4d71eb26a2828ff37fe700ae55530d9fff711d.

This reverts commit b0c962468a54affd3eaad8a5df698287d5a1ab4f.

This reverts commit 4030f642397f46330670b99cd6252e92684c53a1.

This reverts commit 80f39f5465990c870dac59b61ade4d8c68839fe2.

This reverts commit 8c0e02833303ea1a6a4e57af48278f24672c98ff.

  1. … 64 more files in changeset.
Support capabilities with project dependencies

Previously, it was possible to discover and solve conflicts between published modules, or through the `capabilities` block when

declaring capabilities for external modules. With this commit, it is now possible to declare capabilities in projects that are

used during conflict resolution.

  1. … 29 more files in changeset.
Consume capabilities from external modules

This commit introduces the ability to consume capabilities from external

modules. This is a pretty big change for multiple reasons:

- capabilities are no longer known beforehand (before resolution starts) but

can be discovered as we add more nodes to the graph

- conflict resolution cannot fail fast anymore, since it is possible for a

module to declare a capability that triggers a conflict with another module

in the graph, but a 3rd party module can express a preference

- capabilities are consumed from Gradle metadata files

- capabilities from the local component and capabilities from the graph are

merged during resolution

Capabilities are, in published metadata, available at the component level,

with the assumption that capabilities are the same for all variants. It is

not necessary for a module to express a preference for a capability, as

a 3rd party module can declare only a preference, for example.

  1. … 49 more files in changeset.
Fix spelling metaData -> metadata

  1. … 1 more file in changeset.
Introduce in-memory versions of dependency caches

Currently, local file repositories use a completely separate caching

infrastructure for in-memory caching. This makes the code difficult

to understand, and can lead to subtle differences (bugs) between

resolution against remote and local repositories.

This commit introduces in-memory versions of the four key resolution

caches, which will be used to consolidate caching infrastructure

between local and remote repositories.

These caches are not yet used.

    • -52
    • +26
    ./DefaultModuleMetadataCache.java
    • -0
    • +75
    ./InMemoryModuleMetadataCache.java
    • -0
    • +51
    ./artifacts/ArtifactsAtRepositoryKey.java
    • -0
    • +29
    ./artifacts/CachedArtifacts.java
    • -0
    • +45
    ./artifacts/DefaultCachedArtifacts.java
    • -108
    • +20
    ./artifacts/DefaultModuleArtifactsCache.java
    • -0
    • +55
    ./artifacts/InMemoryModuleArtifactCache.java
    • -0
    • +76
    ./artifacts/InMemoryModuleArtifactsCache.java
    • -72
    • +20
    ./dynamicversions/DefaultModuleVersionsCache.java
    • -0
    • +69
    ./dynamicversions/InMemoryModuleVersionsCache.java
    • -0
    • +42
    ./dynamicversions/ModuleAtRepositoryKey.java
    • -2
    • +2
    ./dynamicversions/ModuleVersionsCacheEntry.java
  1. … 3 more files in changeset.
Got rid of separate in-memory caching layer for local repos

Local file repositories now use the regular `CachingModuleComponentRepository`,

but provide in-memory-only versions of the dependency resolution caches

in order to retain the current 'always-refresh' behaviour.

    • -0
    • +79
    ./ResolvedArtifactCaches.java
  1. … 14 more files in changeset.
Add a simple provider for caches used by CachingModuleComponentRepository

    • -0
    • +28
    ./ModuleRepositoryCacheProvider.java
    • -0
    • +34
    ./ModuleRepositoryCaches.java
  1. … 5 more files in changeset.
Fixed some incorrect spelling: MetaData -> Metadata

    • -0
    • +68
    ./DefaultCachedMetadata.java
    • -179
    • +0
    ./DefaultModuleMetaDataCache.java
    • -0
    • +179
    ./DefaultModuleMetadataCache.java
    • -0
    • +56
    ./ModuleMetadataCache.java
  1. … 21 more files in changeset.
Moved module artifact cache to live with other module caches

    • -228
    • +0
    ./DefaultModuleArtifactsCache.java
    • -0
    • +56
    ./artifacts/ArtifactAtRepositoryKey.java
    • -0
    • +28
    ./artifacts/CachedArtifact.java
    • -0
    • +64
    ./artifacts/DefaultCachedArtifact.java
    • -0
    • +157
    ./artifacts/DefaultModuleArtifactCache.java
    • -0
    • +228
    ./artifacts/DefaultModuleArtifactsCache.java
    • -0
    • +63
    ./artifacts/ModuleArtifactCache.java
    • -0
    • +38
    ./artifacts/ModuleArtifactsCache.java
  1. … 15 more files in changeset.
Moved module version-list cache to live with other metadata caches

    • -0
    • +38
    ./dynamicversions/DefaultCachedModuleVersionList.java
    • -0
    • +166
    ./dynamicversions/DefaultModuleVersionsCache.java
    • -0
    • +36
    ./dynamicversions/DefaultResolvedModuleVersion.java
    • -0
    • +34
    ./dynamicversions/ModuleVersionsCache.java
    • -0
    • +28
    ./dynamicversions/ModuleVersionsCacheEntry.java
  1. … 13 more files in changeset.
Cache processed metadata in-memory

Processing component metadata rules for resolved module metadata

is expensive, and the fix for #3019 introduced a serious performance

regression. This change adds in-memory caching for the post-processed

metadata on a per-repository basis.

Unfortunately, this re-introduces the bug #4261, where component

metadata rule outputs can leak between projects for a repository.

Since defining different metadata rules in different projects is

unlikely to be commonplace, this is considered an acceptable

interim position. This issue should be addressed with the

introduction of general-purpose caching of component metadata

rules.

  1. … 2 more files in changeset.
Preserve Maven snapshot ID through dependency resolution

When resolving a Maven snapshot that has a unique timestamp, Gradle internally

generates a unique component identifier for this snapshot. Previously this

unique snapshot id was discarded during resolution, meaning that artifacts from

different unique snapshots could have the same identifier.

With this change, the `MavenUniqueSnapshotIdentifier` is preserved in

resolution, and is made available via the resolution result.

This change is required to fix #3019 for maven snapshots, to avoid the

in-memory cache of resolved artifacts providing a stale result for

unique snapshot artifacts.

  1. … 4 more files in changeset.
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 <cedric@gradle.com>

  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

to:

- 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 <cedric@gradle.com>

  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.