Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename inheritStrictVersions() -> endorseStrictVersions() (#10755)

This name change more clearly communicates the semantics of the

feature from a users point of view.

This commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

would have been misleading in the future. To make sure we catch all,

this also updates all variable/method/package names.

  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

  1. … 70 more files in changeset.
Rename inheritStrictVersions() -> endorseStrictVersions()

This is more clearly communicating the semantics of the feature

from a users point of view.

The commit also removes all mentions of 'inheriting' AND 'forSubgraph'.

There have been some leftovers in documentation/comments that

will be misleading in the future. To make sure we catch all,

I also updated all variable/method/package names.

  1. … 70 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

  1. … 79 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

  1. … 77 more files in changeset.
Rework `forSubgraph` as implied by `strictly`

This commit removes a dedicated `forSubgraph` flag

on version constraints, so that it is _implied_ by

strict version constraints. This simplifies the behavior

of `strictly`, making it closer to the intuitive semantics,

while maintaining the ability to fail the build if a

consumer brings an incompatible version in the graph.

As a consequence, _strict dependencies_ now express that

the producer preference overrides whatever is found in

its own dependency graph. It is closer to the "nearest

first" semantics of Maven, while not having its drawbacks

(ordering in particular).

  1. … 77 more files in changeset.
Add test coverage for artifact selectors in GMM

  1. … 5 more files in changeset.
Add test coverage for artifact selectors in GMM

  1. … 8 more files in changeset.
Introduce constraint inheritance API

  1. … 40 more files in changeset.
Introduce constraint inheritance API

  1. … 40 more files in changeset.
Introduce constraint inheritance API

  1. … 40 more files in changeset.
Introduce constraint inheritance API

  1. … 41 more files in changeset.
Add `inheritSubgraphConstraints()` API to dependencies

  1. … 61 more files in changeset.
Add `inheritSubgraphConstraints()` API to dependencies

  1. … 62 more files in changeset.
Add `inheritSubgraphConstraints()` API to dependencies

  1. … 63 more files in changeset.
Make Gradle metadata format 1.0

This commit bumps the Gradle metadata format to 1.0.

The specification file of the format has been changed

so that the name of the file indicates which version

it covers.

Starting from this commit, it is illegal to change

the metadata file format _without_ backwards compatibility

in mind.

  1. … 6 more files in changeset.
spelling: require

Signed-off-by: Josh Soref <jsoref@users.noreply.github.com>

Update module metadata specification

  1. … 1 more file in changeset.
Separate 'prefer' and 'require' in dependency versions

When we introduced the ability to declare a 'preferred' version on

a dependency declaration, this was implemented such that declaring

a "required" dependency version using `org:foo:1.0` was effectively

the same as declaring a "preferred" version `org:foo { prefer '1.0' }`.

In order to differentiate between the behaviour of required and

preferred dependency versions, this commit introduces a separate

model for these constraint types. This model is published to

Gradle `.module` metadata files, and is retained internally

throughout dependency resolution.

At this stage, the behaviour of required and preferred versions

is identical. A later commit will introduce the behavioural

difference.

  1. … 35 more files in changeset.
Retain separate versions for 'strictly' and 'prefers'

Previously, a `strictly` version constraint was translated into a separate

'prefer' and 'reject' constraint: this is how it was processed internally,

as well as how it was represented in a `.module` file.

With this change, strict version constraints are logically retained as a

first class version constraint:

- `.module` files can have versions declared with `strictly`

- Strict constraints are only translated to a reject version selector

as part of resolution (not when parsing the constraint)

  1. … 24 more files in changeset.
Resurrect and fix DefaultModuleArtifactCacheTest

  1. … 2 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.
Read dependency attributes in Gradle module metadata

This commit adds support for parsing dependency attributes in Gradle module metadata.

It is not yet making use of that information, it's only making sure that the parser

is able to parse and propagate it. It doesn't touch the serializer either, which is

going to be done in a separate commit.

Module metadata file version has been bumped to 0.4 as part of this work.

  1. … 10 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.