Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Serialization of realised ModuleComponentResolveMetadata

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

values.

Fixes #5653

  1. … 14 more files in changeset.
Serialization of realised ModuleComponentResolveMetadata

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

values.

Fixes #5653

  1. … 14 more files in changeset.
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

  1. … 5 more files in changeset.
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

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

  1. … 18 more files in changeset.
Bump cache layout format for #4765

The scope of each dependency management entry is cached.

  1. … 2 more files in changeset.
Bump cache layout format

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

  1. … 2 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.
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.
Merge branch 'release'

Increase cache layout version because this combines different

metadata parsing changes for 4.5.1 and 4.6

  1. … 2 more files in changeset.
Revert: Add scope to maven dependency key (#4244)

Revert: Add scope to maven dependency key

Reverts a82cf4a but increases the cache layout version, as this

is now a new combination of changes.

It fixes #4202 and adds a test for 'duplicated dependency management entries override behavior' which covers the reported issue.

  1. … 9 more files in changeset.
Bump metadata cache layout version

  1. … 2 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 scope to maven dependency key

Different versions could be defined for compile/runtime scope in

the dependency management block.

This is for example how Gradle publishes dependency constraints

to <dependencyManagement> for the same dependency with different

versions in a Java Library:

<dependencyManagement>

<dependencies>

<dependency>

<groupId>org.test</groupId>

<artifactId>bar</artifactId>

<version>1.0</version>

<scope>compile</scope>

</dependency>

<dependency>

<groupId>org.test</groupId>

<artifactId>bar</artifactId>

<version>1.1</version>

<scope>runtime</scope>

</dependency>

</dependencies>

</dependencyManagement>

Signed-off-by: Jendrik Johannes <jendrik@gradle.com>

  1. … 8 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.
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.
Bump cache layout version

  1. … 2 more files in changeset.
Bump cache layout version

  1. … 2 more files in changeset.
Bump the metadata cache layout version

  1. … 2 more files in changeset.
Bump the metadata cache version for addition of excludes

  1. … 2 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.
Add support for maven BOMs through optional dependencies

- If a "pom" only contains a <dependencyManagement> block and no

<dependencies> block, it is interpreted as "bom"

- Each dependency from the <dependencyManagement> block is then

added as optional dependency

  1. … 7 more files in changeset.
Make `ModuleComponentSelector` the source of truth for version constraints

This commit pushes `VersionConstraint` as a primary concept in `ModuleComponentSelector`. It replaces the (now)

deprecated `getVersion` call, which didn't reflect all possible constraints on a version. This change has several

consequences:

- version constraints now need to be "serializable"

- version constraints now consist of a preferred version and a list of rejected versions

- only a single item in the rejection list is supported

- Gradle module metadata parsing now generates a prefer/reject list

- Gradle module metadata writing does **not** yet support writing prefer/reject

- the module metadata binary format has been bumped to support prefer/reject in module descriptors

- metadata rules can say `useTarget(VersionConstraint)`

Issue #3312

  1. … 93 more files in changeset.
Fixed handling of boolean typed attributes in cached module metadata. Incremented the cache layout version due to a change in the serialized format of the metadata.

  1. … 4 more files in changeset.
Include the dependency information extracted from the module metadata file in the persistent metadata cache. The information is not used during dependency resolution yet.

Incremented the artifact cache metadata version.

  1. … 6 more files in changeset.
Changed downloaded artifact caching to honor the artifact's file name as defined in the module metadata file. This allows the producer to use an arbitrary file name that makes sense for the particular artifact, rather than being constrained to using a Maven classifier and extension.

The file name is not honored for local repositories yet.

Incremented the cache layout format version due to changes to the persisted metadata.

  1. … 14 more files in changeset.
Changed the cache layout version to reflect changes to persistent metadata contents.

  1. … 2 more files in changeset.
Moved the module level exclude rule definitions and branch property for Ivy metadata from the legacy `ModuleDescriptorState` onto the relevant metadata types. The Maven metadata has no module level excludes or branch property, so don't persist these for Maven modules.

Incremented the cache layout version to reflect the changes to the persisted metadata.

  1. … 26 more files in changeset.
Moved the artifact definitions for Ivy and Maven metadata from the legacy `ModuleDescriptorState` onto the relevant metadata types. The Maven metadata always includes a single hard-coded artifact, so don't persist the artifact definitions for Maven modules.

Changed the Maven metadata implementation so that the Jar artifact is attached to the 'compile' configuration and is inherited by the other configurations. Previously the artifact was attached to the 'default' configuration.

Incremented the cache layout version to reflect the changes to the persisted metadata.

  1. … 31 more files in changeset.