Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.
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

sense.

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.