DependencyMapNotationConverterTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Allow the services required by a given class to be queried prior to creating any instances of that class. Use this to allow `ArtifactTransformDependencies` to be injected into artifact transforms using any of the service injection patterns (that is, via a constructor or a getter).

    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
  1. … 127 more files in changeset.
Replace most direct usages of `DirectInstantiator` with indirect usages via `InstantiatorFactory` or test fixtures instead. This means more consistent behaviour in unit tests because the objects under test will behave more similarly to how they do at runtime. This also allows the decision of how the instantiation should behave to live in as few places as possible, so this can be more easily evolved and contextualized.

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

    • -8
    • +8
    ./DependencyMapNotationConverterTest.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.

    • -8
    • +8
    ./DependencyMapNotationConverterTest.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.

    • -8
    • +26
    ./DependencyMapNotationConverterTest.groovy
  1. … 36 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.

    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
  1. … 164 more files in changeset.
Ensure MutableVersionConstraint does not have null preferredVersion

While the interface for `VersionConstraint` declared that version was

`@Nullable`, in reality we prevented this when constructing an immutable

version constraint. This meant that `MutableVersionConstraint.asImmutable()`

converted null values to empty strings.

This changes the contract so that `VersionConstraint.preferredVersion` is no

longer `@Nullable`, and an empty string is consistently used to define a

'missing' preferred version, for all implementations of `VersionConstraint`.

    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
  1. … 6 more files in changeset.
Restore ability to use `null` version in DSL

The DSL was the only place where `null` as version was allowed. Unfortunately changing this broke the Spring

Dependency Management plugin, so we need to rollback the change and introduce a workaround for version constraints,

using the `normalize()` method.

    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
  1. … 6 more files in changeset.
Adjust `Dependency` and module selection to use `VersionConstraint`

This fixes the mismatch between immutable and mutable version constraints.

    • -0
    • +18
    ./DependencyMapNotationConverterTest.groovy
  1. … 32 more files in changeset.
Support strict dependencies thanks to `accept`/`reject` primitives

This commit introduces support for strict dependencies. Strict dependencies are constraints on the

versions of dependencies in the graph. When a dependency version is strict, it is expected that no

other dependency disagrees with it. It means that:

- if `A` says `strictly 1.0`, but `B` says `1.1`, then the build will fail

- if `A` says `strictly [1.0, 2.0)`, and `B` says `1.1`, then `1.1` will be selected

- if `A` says `strictly 1.1`, but `B` says `1.0`, then `1.1` is selected

Implementation-wise, a dependency version is now represented as a `ModuleVersionConstraint`, which

will internally be exposed as 2 different primitives:

- `preferred`, a `VersionSelector` that selects the _preferred version_ (or baseline) of a dependency

- `reject`, a `VersionSelector` which allows _rejecting_ specific versions

This commit does **not** address publication of such constraints.

    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
  1. … 26 more files in changeset.
Add unit tests for `targetConfiguration`

This ensures that `targetConfiguration` is `null` when nothing is specified in the dependency notation, whereas

it is `default` when an explicit `default` configuration is used. This is important to determine whether an

explicit `default` configuration is used, compared to falling back to the default configuration.

+review REVIEW-6242

    • -0
    • +30
    ./DependencyMapNotationConverterTest.groovy
Remove the use of `Optional` in `ProjectDependency#getTargetConfiguration`

+review REVIEW-6242

    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
  1. … 13 more files in changeset.
Deprecate `ModuleDependency#getConfiguration` in favor of `ModuleDependency#getTargetConfiguration`

We want to be able to differentiate between two cases when dependencies on projects are declared:

1. the user didn't choose any specific configuration

2. the user chose a configuration, and it can be the same as the default one

The previous implementation required that `getConfiguration` returns a non-null value, making it impossible to

make a difference between the following cases:

`compile project(':')`

and

`compile project(path: ':', configuration: 'default')`

The new `getTargetConfiguration` method returns an `Optional<String>`, which will be `absent` if the user

didn't choose anything specific, and `present` if he did.

This allows us to make an explicit configuration selection take precedence over automatic configuration

selection when attributes are defined.

    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
  1. … 15 more files in changeset.
Make DirectInstantiator a singleton.

    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
  1. … 89 more files in changeset.
Changed tests to use NotationParserBuilder instead of wiring stuff together in an ad hoc way.

    • -2
    • +3
    ./DependencyMapNotationConverterTest.groovy
  1. … 4 more files in changeset.
NotationParser to NotationConverter - Convert various implementations - Remove NotationParserBuilder.parser method - Rename implementations of NotationConverter that had a suffix 'Parser'

    • -0
    • +138
    ./DependencyMapNotationConverterTest.groovy
  1. … 69 more files in changeset.