DefaultModuleComponentSelectorTest.groovy

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

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  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).

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 77 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 19 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 19 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 20 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 20 more files in changeset.
Add `forSubgraph()` API to version constraints

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 19 more files in changeset.
Add `strong()` API to version constraints

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 16 more files in changeset.
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.

    • -9
    • +32
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 63 more files in changeset.
Include version constraint details in ModuleComponentSelector.displayName

    • -4
    • +4
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 8 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

    • -1
    • +1
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 64 more files in changeset.
Don't implicitly add 'prefer' with 'require'

    • -3
    • +3
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 11 more files in changeset.
Ensure that 'preferredVersion' always provides a useful value

Recent versions of the build scan plugin depend on `VersionConstraint.preferredVersion`

to return a string representation of the version constraint. This was broken with the

recent introduction of `requiredVersion`, where `preferredVersion` only returned a

value when explicitly set with `prefers(version)`.

This change restores the previous functionality: a `requires` version constraint implies

a `prefers` constraint, and a `strictly` constraint implies a `requires` constraint.

    • -4
    • +4
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 18 more files 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.

    • -5
    • +11
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 36 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)

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 25 more files in changeset.
Normalize `ModuleIdentifier`

This commit reworks the `ComponentModuleIdentifier`/`ComponentModuleSelector`/`ModuleVersionSelector`

classes to use `ModuleIdentifier` under the hood, instead of storing denormalized strings. This has

the advantage that we can reduce the use of the module identifier factory, which is called very

often during dependency resolution. Sharing instances reduces the need for conversions, and makes

comparisons faster.

    • -18
    • +19
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 164 more files in changeset.
Move attributes from dependency metatada to component selector

This commit changes the location where attributes on dependencies are defined, making

them effectively part of the _module component selector_. It's cleaner as it effectively

belongs to the selector state: attributes participate in the selection like group, name

and version.

It will also make module metadata serialization consistent.

    • -16
    • +52
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 27 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.

    • -16
    • +5
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 18 more files in changeset.
Include the requested branch name in the 'version not found' error message, if specified, and do not include the requested version, if not specified.

    • -40
    • +63
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 6 more files in changeset.
Make `ModuleComponentSelector` use `ImmutableVersionConstraint`

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 8 more files in changeset.
Rename `DefaultVersionConstraint` to `DefaultMutableVersionConstraint`

... and use the immutable version whenever possible.

    • -2
    • +2
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 63 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

    • -8
    • +20
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 93 more files in changeset.
Revert De-duplicate commonly used immutable objects in dependency resolution and IDE changes

Commits reverted:

- 807b1e4f8d1585d93c1de3e9ca83d99d0819e2d2

- 9482b0b05374253cafdb776550d7016385912e04

- 4ecead06b53ec6b0f15c517bf0d0c6a74c3b3c05

- db1135a8a5f1c507e0df3c03ad12ddc963799e4d

- 7350bcbae30a777909cec74ebfd5a91d2c89081e

Additionally, minor changes to avoid usage of introduced

classes and methods from subsequent commits.

Issue: gradle/gradle-private#563

    • -8
    • +8
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 109 more files in changeset.
De-duplicate (= intern) some instances in dependency resolution

- Reduce memory usage of dependency resolution by de-duplicating the

most commonly used immutable instances.

- Objects aren't strictly immutable: displayName is calculated lazily

- solution is thread-safe without synchronization

- lazy calculation is needed for efficient interning since a lookup

will always create a new instance.

- Use strong references in some instance interners

- strong references cause less GC overhead than weak references

- Strong references:

DefaultModuleIdentifier

DefaultModuleVersionIdentifier

DefaultModuleVersionSelector

DefaultModuleComponentIdentifier

DefaultModuleComponentSelector

DefaultProjectComponentSelector

- Weak references:

DefaultLibraryBinaryIdentifier

DefaultLibraryComponentSelector

DefaultIvyArtifactName

- Both reference types:

DefaultBuildIdentifier

DefaultProjectComponentIdentifier

- The reason for special handing is that DefaultBuildIdentifier

has a state field "current" as part of the instance which

isn't part of equals/hashCode.

+review REVIEW-6277

    • -8
    • +8
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 104 more files in changeset.
Moved test factory methods out of production code

    • -1
    • +1
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 19 more files in changeset.
Always use factory method to create ProjectComponentId

    • -3
    • +3
    ./DefaultModuleComponentSelectorTest.groovy
  1. … 24 more files in changeset.