Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add error message in case GMM doesn't declare variants

This commit validates that published Gradle Module Metadata

declares at least one variant when resolved. This is the

counterpart to validation at publication time, but this time

when resolving, in case a user/plugin generates module metadata

in a non-Gradle compatible way.

  1. … 6 more files in changeset.
Add error message in case GMM doesn't declare variants

This commit validates that published Gradle Module Metadata

declares at least one variant when resolved. This is the

counterpart to validation at publication time, but this time

when resolving, in case a user/plugin generates module metadata

in a non-Gradle compatible way.

  1. … 6 more files in changeset.
Module test fixture: add 'category' attribute to api/runtime variants

This reflects the default variant attributes of a published

java component.

  1. … 13 more files in changeset.
Module test fixture: add 'category' attribute to api/runtime variants

This reflects the default variant attributes of a published

java component.

  1. … 13 more files in changeset.
Do not drop variant attributes for 'traditional' maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

  1. … 27 more files in changeset.
Do not drop variant attributes for 'traditional' maven artifacts

FixedComponentArtifacts dropped the variant attributes (stored in

ConfigurationMetadata) for no clear reason. Because of this, the

attributes in the resolve result differed depending on whether the

variant was constructed from pom or GMM.

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

  1. … 54 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.
Rename the internal and test fixtures `VariantMetadata` to avoid confusion

Signed-off-by: Cedric Champeau <cedric@gradle.com>

  1. … 25 more files in changeset.
Extend repository test fixtures

This adds:

- Support to define artifacts per variant.

- Support to define dependencies per variant.

- Support to define which metadata a repository is expected to

provide. This is used to define the request assertions when the

`metadataSources { }` api is used.

  1. … 18 more files in changeset.
Publish Gradle metadata on Ivy repositories

This commit adds support for publishing Gradle metadata on Ivy repositories. Existing tests haven't been

adapted yet.

  1. … 9 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.
Change repository test fixtures to allow the repository path and backing file of artifacts to be queried by test.

  1. … 17 more files in changeset.
Added some int test coverage for interaction between Maven scopes and Ivy configurations.

  1. … 27 more files in changeset.
introduced common abstraction for Ivy and Maven repo/module test fixtures

  1. … 11 more files in changeset.