CacheLayoutTest.groovy

Add `strong()` API to version constraints

Spike: requireTransitive()

Further deduplication of serialized metadata

Maven dependency metadata de-duplication now happens as well when

serializing untransformed metadata.

Fixes #8311

Introduce ecosystem registration

This commit introduces the concept of "ecosystem", that can be

registered on an attributes schema. When a component is published,

it may provide a list of ecosystems. This list is used by consumers

when resolving. If, for some reason, variant resolution fails, and

that the consumer didn't use a plugin which provides the expected

ecosystem, the error message will indicate that they probably

miss a plugin that understands that ecosystem.

This is useful when a plugin extends an existing ecosystem with

additional attributes, that consumers may not be aware of. In

this case it is expected that the plugin declares an ecosystem.

Currently the error message will only indicate what ecosystem

is missing, and an optional description. It will not tell _how_

such plugin can be found, nor what plugins provide it.

By default, for adhoc components, publishing will use the

ecosystems of the producer. For example, for a Java project,

the published Gradle metadata file will include the java

ecosystem requirement.

For components which are not adhoc, they must implement the

`ComponentWithEcosystems` interface in order to tell which

ecosystems are in use.

Use real cache version

(the previous one was to avoid CI conflicts)

Support requested capabilities on external dependencies

This commit adds support for having requested capabilities

part of the module component selector, for external dependencies.

This means that if a component is using Gradle metadata, we can

read requested capabilities and honor them during selection.

This reworks where requested capabilities are stored, and in

particular moves them to the `ComponentSelector`, making them

properly part of the identity of a dependency. As such, two

dependencies requiring two different variants by using distinct

capabilities will now properly appear as two different dependencies

in the dependency graph, instead of two variants of the same

dependency.

Move transformer execution history to version specific cache

Use the execution history for artifact transformations

Fix "platform owners" not being serialized

Fix realization of derived variants

This commit changes the way derived variants are handled during serialization.

Before, we used to record only the fact that there were derived variants, and

the realized component metadata class was reproducing what the `getDerivedVariants`

method was doing in the original metadata. Unfortunately, this led to forgetting

about this fact, because in most cases we don't realize all variants eagerly, and

test coverage was missing.

Instead, now, the realized component metadata makes use of the original derived

variants and _serializes_ them. This is only done for Maven metadata now, as this

is the only component type which actually produced derived variants.

This commit also introduces a new test suite called `ForceRealizeTest` which runs

the full integration test suite, but forcing the realization of all variants. This

can be executed typically by running `myProject:integForceRealizeTest`. This test

suite runs in embedded mode by default, in order to be fast.

Bump cache layout version

It is unclear whether this version should have been upgraded before or with this PR,

but this makes the results from cache correct again.

Bump cache version for module metadata

Bump cache layout version for changes to `VersionConstraint`

Remove `repositoryName` from `ModuleSource` API

- Using `ModuleSource` to transport the repository name is a bit of a

mis-use of this type, which was intended to be an opaque memento of

resolution state. (Despite the name indicating otherwise).

- This commit removes `repositoryName` from the API:

This is now only available on the `RepositoryChainModuleSource`,

which attaches a repository identifier to the resolved component result

(in order that it can later look for artifacts in the same repository only).

Add support for emitting information about repositories used during configuration resolution process, and sourced repository for a component (#5959)

- `ResolveConfigurationDependenciesBuildOperationType.Details` now contains a `List<Repository>` eventually provided by all `ResolutionAwareRepository` implementations

- `ResolvedComponentResult` has been subclassed to `ResolvedComponentResultInternal`, to provide the `repositoryName` used as source. This can be `null` in case of project dependency.

- Note that even when artifacts are resolved from the cache, they still convey the original repository that was used as source. The `name` of a repository is guaranteed to be unique inside a given repository container, and we use a single repository container to resolve a given configuration. Hence, the name can be safely used to uniquely identify which repository was used to source components.

- This commit also moves custom serialization logic to the owning type of `SerializedOperation` implementations to their owning types

Handle multi-component cache versions

- Let `UnusedVersionsCacheCleanup` handle cache versions with multiple

components, e.g. metadata-2.58.

- Introduce `CacheVersion` to handle formatting and parsing in one

place.

Serialization of realised ModuleComponentResolveMetadata

This enables proper caching by making sure we can save and reload cache

values.

Fixes #5653

Introduce CacheVersionMapping

Instead of just having a constant for the latest, currently used cache

version, we need to keep track of which cache version is used by which

Gradle version. This way, we can determine which shared cache

directories are safe to delete because there is no Gradle version that

uses it anymore.

Issue: #5807

Support POM exclusions with implicit wildcard

A POM exclusion can specify only the groupId or the artifactId, implying

that the other one is set as "*".

Bump metadata cache version as we now parse more excludes than before.

Fixes #5092

Serialize dependency attributes metadata

Now that module metadata may contain dependencies with attributes, we need to serialize them too.

This commit updates the component selector serializer, as well as the module metadata serializer,

to use this information, effectively bumping the cache metadata layout format version.

Bump cache layout format for #4765

The scope of each dependency management entry is cached.

Bump cache layout format

This is to avoid an issue with CI, format 54 was used in a previous spike.

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.

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.

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.

Merge branch 'release'

Increase cache layout version because this combines different

metadata parsing changes for 4.5.1 and 4.6

Bump metadata cache layout version

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>