Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Introduce shorthand notation for strict versions

This commit introduces a modifier (!!) that can be

used in version strings to introduce a strict version.

For example, the following notation:

org:foo:1.0!!

is equivalent to:

version { strictly '1.0' }

And this notation:

org:foo:[1.0,2.0]!!1.5

is equivalent to:

version {

strictly '[1.0, 2.0]'

prefer '1.5'

}

    • -2
    • +40
    ./DependencyStringNotationConverterTest.groovy
  1. … 2 more files in changeset.
Introduce shorthand notation for strict versions

This commit introduces a modifier (!!) that can be

used in version strings to introduce a strict version.

For example, the following notation:

org:foo:1.0!!

is equivalent to:

version { strictly '1.0' }

And this notation:

org:foo:[1.0,2.0]!!1.5

is equivalent to:

version {

strictly '[1.0, 2.0]'

prefer '1.5'

}

    • -2
    • +40
    ./DependencyStringNotationConverterTest.groovy
  1. … 2 more files in changeset.
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

    • -6
    • +2
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 41 more files in changeset.
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

    • -6
    • +2
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 41 more files in changeset.
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

    • -6
    • +2
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 41 more files in changeset.
Replace usages of `FileResolver.resolveFile()` with `FileCollectionFactory.resolving()` or `FileOperations.immutable()`, so that `FileResolver` can be responsible only for converting scalar values to File-ish values.

    • -6
    • +2
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 41 more files in changeset.
Fix services not being injected using the Kotlin DSL

When using the Kotlin DSL the attributes factory and

the capability notation parser were not injected

because the `project` method call is not the same as

in the Groovy case.

  1. … 2 more files in changeset.
spelling: identifier

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

    • -1
    • +1
    ./ModuleIdentifierNotationConverterTest.groovy
  1. … 2 more files in changeset.
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
    ./DependencyClassPathNotationConverterTest.groovy
    • -1
    • +1
    ./DependencyMapNotationConverterTest.groovy
    • -3
    • +3
    ./DependencyStringNotationConverterTest.groovy
  1. … 124 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.

    • -3
    • +5
    ./DependencyClassPathNotationConverterTest.groovy
    • -2
    • +2
    ./DependencyMapNotationConverterTest.groovy
    • -4
    • +4
    ./DependencyStringNotationConverterTest.groovy
  1. … 57 more files in changeset.
Refine gradleApi() filtering for optional Kotlin DSL

by relying on classpath registry instead of hardcoded filtering

Signed-off-by: Paul Merlin <paul@gradle.com>

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

    • -8
    • +8
    ./DependencyMapNotationConverterTest.groovy
    • -7
    • +7
    ./DependencyStringNotationConverterTest.groovy
  1. … 10 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
    • -7
    • +7
    ./DependencyStringNotationConverterTest.groovy
  1. … 17 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
    • -7
    • +25
    ./DependencyStringNotationConverterTest.groovy
  1. … 35 more files in changeset.
Validate component identifier parsing

    • -0
    • +89
    ./ComponentIdentifierParserTest.groovy
  1. … 4 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
    • +1
    ./DependencyStringNotationConverterTest.groovy
  1. … 163 more files in changeset.
Intern strings when reading module metadata from cache

Dependency resolution of large dependency graphs involves a significant

number of comparisons of strings(group, artifact, version, ...). Most of

those come from the module metadata cache, and even if we use hashmaps,

we still need to perform `equals` comparisons on strings, when in most

of the cases they should be identical. This commit takes advantage of

knowing that to add a cost when we read module metadata (interning), but

realizing that the debt is paid when comparing strings during resolution.

The interner is build scoped (in order to avoid memory leaks), thread-safe,

and shared with the dependency notation converter, so that module selectors

created from strings found in the build scripts are using the same strings

as the ones from the module metadata cache.

Ideally, we should also do this for the strings used during parsing.

    • -3
    • +4
    ./DependencyStringNotationConverterTest.groovy
  1. … 17 more files in changeset.
Use umodifiable list in DefaultClassPath

This makes accidental mutation impossible and reduces some

of the repeated wrapping.

    • -4
    • +4
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 37 more files in changeset.
defer creation of generated jar to execution time; simplify

    • -3
    • +3
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 2 more files in changeset.
Initial work on creating api jar lazy later in the build lifecycle

- moves the creation of api jar and testkit jar out of configuration time to task graph calculation

- ideally we're able to move it further down

    • -4
    • +4
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 4 more files in changeset.
Allow '+' character in module replacement input

Fixes #1472

    • -2
    • +2
    ./ModuleIdentifierNotationConverterTest.groovy
  1. … 2 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
    • -2
    • +2
    ./DependencyStringNotationConverterTest.groovy
  1. … 5 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
    • -2
    • +2
    ./DependencyStringNotationConverterTest.groovy
  1. … 5 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
    • -0
    • +18
    ./DependencyStringNotationConverterTest.groovy
  1. … 31 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
    • -2
    • +2
    ./DependencyStringNotationConverterTest.groovy
  1. … 25 more files in changeset.
Move org.gradle.api.internal.cache to persistent-cache project

+review REVIEW-6562

    • -1
    • +1
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 85 more files in changeset.
Group logs by project and task

Introduces a BuildOperationType enum and adds it to the

default BuildOperationDescriptor. Passes this information

to the logging infrastructure through the BuildOperationExecutor.

All BuildOperations now have a ProgressLogger. This allows

progress logging to maintain a heirarchy of build operations,

otherwise we would not be able to group many log events.

ProgressStartEvents are given additional information in a

compact form to allow a tree of build operations to be

maintained and their operation types associated. This allows us

to associate log events who aren't fired by progress logging to

still be grouped.

A LogGroupingOutputEventListener uses these build operation

types and the build operation heirarchy to buffer and output

logs related to tasks and project configurations.

Issue: #1818

    • -2
    • +2
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 30 more files in changeset.
Use the module identifier factory in `ModuleIdentifierNotationConverter`

This involves the creation of some "static" factories, but we can keep them for performance reasons (the converters

were made static in performance burst #2 to avoid the creation of too many converters). There will be duplicated

module ids, but not as much as before.

Also the `ModuleExclusions` class now needs to provide a factory, which also goes into the direction we need: make

it a proper service where we will be able to introduce caches for faster merging of exclude rules.

    • -2
    • +8
    ./ModuleIdentifierNotationConverterTest.groovy
  1. … 8 more files in changeset.
Use a specific artifact identifier for files added for `gradleApi()`, `gradleTestKit()` and `localGroovy()` dependencies, to give some clue as to where these files came from.

    • -45
    • +56
    ./DependencyClassPathNotationConverterTest.groovy
  1. … 14 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