Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Apply `Explicit type can be replaced with <>` inspection the whole project

    • -2
    • +2
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 909 more files in changeset.
Add missing @Override to all modules

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

    • -0
    • +2
    ./BuildableModuleComponentMetaDataResolveResult.java
    • -0
    • +2
    ./BuildableModuleVersionListingResolveResult.java
    • -0
    • +1
    ./DefaultBuildableArtifactResolveResult.java
    • -0
    • +8
    ./DefaultBuildableComponentIdResolveResult.java
    • -0
    • +7
    ./DefaultBuildableComponentResolveResult.java
    • -0
    • +8
    ./DefaultBuildableModuleVersionListingResolveResult.java
    • -0
    • +4
    ./DefaultResourceAwareResolveResult.java
  1. … 996 more files in changeset.
Add missing @Override to all modules

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

    • -0
    • +2
    ./BuildableModuleComponentMetaDataResolveResult.java
    • -0
    • +2
    ./BuildableModuleVersionListingResolveResult.java
    • -0
    • +1
    ./DefaultBuildableArtifactResolveResult.java
    • -0
    • +8
    ./DefaultBuildableComponentIdResolveResult.java
    • -0
    • +7
    ./DefaultBuildableComponentResolveResult.java
    • -0
    • +8
    ./DefaultBuildableModuleVersionListingResolveResult.java
    • -0
    • +4
    ./DefaultResourceAwareResolveResult.java
  1. … 990 more files in changeset.
Implement Gradle metadata marker in published pom/ivy files

This commit implements a performance optimization for Gradle metadata.

Given that today there's no library published in any repository with

Gradle metadata, it's much more likely to find a POM (or Ivy) metadata

file for an external dependency, rather than a Gradle metadata file.

If we decided to add `gradleMetadata()` sources by default to all

repositories, then we would probably introduce a performance regression

to a lot of builds, because we would first try to get Gradle metadata,

then fail, and search for POM/Ivy files.

To avoid this, whenever a library is going to be published with Gradle

metadata, we will introduce a _marker_ in the published POM or Ivy

file. When Gradle _resolves_ such a dependency, it will parse the POM

file and look for the marker. If it finds it, then it will _redirect_

to use Gradle metadata instead. This means that when Gradle metadata is

present, we will pay the price of looking for a POM or Ivy file first,

start parsing, only to discover we should parse Gradle metadata. This

should be ok in the beginning, knowing that if `gradleMetadata()` is

added, then we would systematically look at Gradle metadata first.

This means that this is a _temporary_ solution, until Gradle metadata

becomes widespread. So "temporary" should be understood as several

months, if not years.

The marker introduced in POM and Ivy files is _neutral_ for both Ivy

and Maven. By this we mean that it uses an XML comment. While not super

nice, we couldn't use a custom namespace because both Ivy and Maven

fail when parsing this. Properties were considered too, but Ivy doesn't

support them so for consistency both models use comments.

It's worth noting that we will still _completely parse_ the POM or Ivy

descriptor. It's a waste of time, but it helps in case we find a marker

but that for some reason the Gradle metadata file is absent. In this

case we fallback on the model we found.

This change also introduces a change in the semantics of the incubating

metadata sources API: those should be considered _hints_, and not strong

statements anymore.

Finally, should a producer want to avoid publishing Gradle metadata,

it's now possible to disable the task that creates the metadata file.

    • -1
    • +8
    ./BuildableModuleComponentMetaDataResolveResult.java
    • -0
    • +10
    ./DefaultBuildableModuleComponentMetaDataResolveResult.java
  1. … 56 more files in changeset.
Use repository content filtering when selecting dynamic versions

This commit fixes an issue with content filtering, which led to versions

being silently ignored because we were listing versions, _then_ filtering.

Instead, this commit makes sure we actually only return versions which

do participate in the repository.

  1. … 6 more files in changeset.
Track unmatched versions in SelectorState

Previously, when resolving a selector we were registering the unmatched

versions at the component level. The `ComponentState` would keep a map

of selector -> unmatched versions, which would later be reconnected to

the original selector.

With this change, the unmatched versions are kept with the `SelectorState`

until required to form a component selection reason. This simplifies the

logic and reduces the number of collection copies required.

    • -2
    • +1
    ./BuildableComponentIdResolveResult.java
    • -5
    • +4
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 9 more files in changeset.
Implement retries with exponential backoff

This commit reworks the strategy used to blacklist repositories. In the case

an error occurs when trying to access a remote resource, if the error is not

a missing resource, we're going to retry twice before actually blacklisting.

Between each try, we're going to wait, and the wait is increasing between

each trial exponentially. There are two internal parameters which allow

tweaking the behavior:

- `org.gradle.internal.repository.max.retries` (default 3) is the number

of retries (initial included)

- `org.gradle.internal.repository.initial.backoff` is the initial time

before retrying, in milliseconds (default 125)

Fixes #4629

    • -1
    • +1
    ./BuildableModuleComponentMetaDataResolveResult.java
    • -1
    • +1
    ./BuildableModuleVersionListingResolveResult.java
    • -3
    • +5
    ./DefaultResourceAwareResolveResult.java
    • -0
    • +32
    ./ErroringResolveResult.java
  1. … 6 more files in changeset.
Do not try to infer if a platform is virtual

This commit removes the ability of the engine to determine that a platform

is virtual when it's not marked as such. This means that we effectively

trust the user calling the right `belongsTo` method. By doing this, it

allows us to remove the `retryIfMissing` complexity.

    • -6
    • +0
    ./BuildableComponentResolveResult.java
    • -10
    • +0
    ./DefaultBuildableComponentResolveResult.java
  1. … 5 more files in changeset.
Trust missing components when resolution is trying a virtual platform

This commit adds a special case in the resolution engine for missing modules.

The default behavior, when a module is missing, is to cache the result. However,

when there are multiple repositories, it is possible for a module to be found

in a subsequent repository, in which case the result is deemed authoritative,

and we wouldn't try again on the repositories which had "missing metadata". But,

for UX reasons, if a module is missing from _all_ repositories, we would always

try again on the next build, despite knowing that the module would be absent.

This was intended to solve the following use case:

- BuildA attempts to resolve org:module:1.1, but the user forgot to publish this module version, so resolution fails

- BuildB executes, publishing org:module:1.1

- BuildA executes again, without using --refresh-dependencies. We prefer making additional network calls rather than failing the build again.

This behavior interferes with the "virtual platform" use case, where we need

to pre-emptively try to find a module, without knowing if it actually exists.

This commit adds a flag, `retryMissing`, which is by default `true`, but can be set

to false when we resolve a module. If so, then the engine will trust the cached missing

status. Virtual platforms (and edges) use this new method, bypassing the old path.

    • -0
    • +7
    ./BuildableComponentResolveResult.java
    • -0
    • +1
    ./BuildableModuleComponentMetaDataResolveResult.java
    • -0
    • +14
    ./DefaultBuildableComponentResolveResult.java
    • -0
    • +1
    ./DefaultBuildableModuleComponentMetaDataResolveResult.java
  1. … 7 more files in changeset.
Avoid the creation of a hashmap to build the resolution result

The resolution result can be quite large, and involves a lot of

resizes of the map, just to collect the nodes which have already

been visited. We replace it with an ad-hoc "mark" method which

is a pure optimization.

    • -0
    • +10
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 1 more file in changeset.
Collect unmatched dependencies too

Without this change, it is not possible to know which versions Gradle

considered for a dynamic range, unless it's rejected by a rule or by

attribute matching.

    • -6
    • +10
    ./BuildableComponentIdResolveResult.java
    • -4
    • +5
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 16 more files in changeset.
Collect unmatched dependencies too

Without this change, it is not possible to know which versions Gradle

considered for a dynamic range, unless it's rejected by a rule or by

attribute matching.

    • -6
    • +10
    ./BuildableComponentIdResolveResult.java
    • -4
    • +5
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 16 more files in changeset.
Associate rejected versions with their constraint or rule

This commit reworks the mapping between rejected versions and

version selectors, so that we can make the difference between

a version which was rejected by a selector (regular or constraint)

or a rule. Then the dependency insight report can properly show

what versions were rejected in which context.

  1. … 18 more files in changeset.
Associate rejected versions with their constraint or rule

This commit reworks the mapping between rejected versions and

version selectors, so that we can make the difference between

a version which was rejected by a selector (regular or constraint)

or a rule. Then the dependency insight report can properly show

what versions were rejected in which context.

  1. … 18 more files in changeset.
Collect all rejections during dependency resolution

This commit collects all rejections during dependency resolution,

so that we can properly show them in the dependency insight report.

This highlights some consistency/readability issues, like when a

rejection originates from a constraint. For this reason this commit

does **not** pass tests, and is just the first step towards better

rendering.

    • -10
    • +0
    ./BuildableComponentIdResolveResult.java
    • -8
    • +26
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 23 more files in changeset.
Collect all rejections during dependency resolution

This commit collects all rejections during dependency resolution,

so that we can properly show them in the dependency insight report.

This highlights some consistency/readability issues, like when a

rejection originates from a constraint. For this reason this commit

does **not** pass tests, and is just the first step towards better

rendering.

    • -10
    • +0
    ./BuildableComponentIdResolveResult.java
    • -8
    • +26
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 23 more files in changeset.
Refactor collection of attempts/rejections in dynamic resolution

This commit adds methods on the buildable component id resolve result

type so that we can properly collect the attempts, rejections and

unmatched versions for each selector.

    • -0
    • +28
    ./BuildableComponentIdResolveResult.java
    • -0
    • +28
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 2 more files in changeset.
Refactor collection of attempts/rejections in dynamic resolution

This commit adds methods on the buildable component id resolve result

type so that we can properly collect the attempts, rejections and

unmatched versions for each selector.

    • -0
    • +28
    ./BuildableComponentIdResolveResult.java
    • -0
    • +28
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 2 more files in changeset.
Improve error reporting in case no matching dynamic version is found

This commit improves rendering of errors in case resolution fails because

all versions in a dynamic range are evicted, and that at least one of the

evicted versions was evicted because of attribute matching. The error will

now report the attributes on each tested version, as well as the requested

attributes.

For this, the module not found exception has been updated to carry more

context, and now makes use of the tree formatter for consistency with other

exceptions in the codebase.

  1. … 37 more files in changeset.
Implement matching of component attributes during dynamic version selection

This commit adds support for matching the component attributes during the selection

of a version, when the selector is dynamic. Before, component-level attributes were

ignored, meaning we could select a version which wouldn't have any variant matching

the consumer attributes. With those changes, it is possible, for example, to have

a version, 1.3, which doesn't match the consumer attributes, and an earlier version,

say 1.2, which does. In that case, 1.2 would be selected instead of 1.3.

The consequence of this change is that we now have to fetch metadata for components

that are selected during dynamic version selection, in order to check if they match

the component attributes. This used to be the case for status selectors (`latest.release`)

but not for version ranges (`[1.0, )`).

It's also worth noting that if the selector is dynamic, we will perform attribute

matching at least twice (possibly with different attribute sets):

- once during version selection (for each candidate, check if its attribute match)

- then once during _variant_ selection (in which case each variant may have additional

attributes)

  1. … 14 more files in changeset.
Add 'rejected' status to `ComponentIdResolveResult`

We now consider all reject constraints when resolving version constraints to a

component identifier. Previously, this knowledge was discarded and we then

re-evaluated the reject constraints to see if the resulting component was indeed

rejected.

With this change, the `ComponentIdResolveResult` retains the knowledge that a

component that was 'selected' for a version constraint is in fact 'rejected'.

This is done for both dynamic and static version constraints, removing the need

to re-check the reject constraint after selection.

    • -0
    • +5
    ./BuildableComponentIdResolveResult.java
    • -0
    • +13
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 6 more files in changeset.
Consider all reject constraints when resolving dynamic versions

When resolving a component selector to a component identifier, we now construct

a unified 'allRejects' constraint that allows the correct resolution of

dynamic versions. If all versions matching a dynamic version are rejected,

then the highest rejected version is chosen. Checking for rejected versions

in the resolved graph is done in a subsequent step, after conflict resolution.

When the set of reject constraints changes there may be a need to re-resolve

a particular component selector. Efforts are made to reduce these situations

by comparing the previously resolved version to the updated set of constraints.

  1. … 12 more files in changeset.
Simplify the collection of selection reasons

It is not necessary to resolve all selectors in order to include them

in the graph. For instance, if the we resolve a fixed version `12`, then

there is no reason to also resolve the version range `[10, 12]`.

For this reason, it should not be necessary to resolve a selector in

order to determine the selection reason. With this change, the selection

reason is no longer part of the `ComponentIdResolveResult`, and is

determined directly when adding the selector to the graph.

    • -6
    • +0
    ./BuildableComponentIdResolveResult.java
    • -15
    • +0
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 6 more files in changeset.
Provide ResolvedVersionConstraint when resolving component id

The 'resolved' version constraint is critical to resolving the component id

for a given selector. In order to honour all constraints in the resolution

process, this `ResolvedVersionConstraint` will be composed of more than

just the constraints for a single selector.

With this change, the `ResolvedVersionConstraint` is constructed

prior to resolving the id, rather than being constructed as part of that

process.

    • -6
    • +0
    ./BuildableComponentIdResolveResult.java
    • -13
    • +0
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 13 more files in changeset.
Rename id accessors for consistency

Use `ComponentIdentifier getId()`

Use `ModuleVersionIdentifier getModuleVersionId()`

    • -1
    • +1
    ./DefaultBuildableComponentIdResolveResult.java
    • -4
    • +4
    ./DefaultBuildableComponentResolveResult.java
  1. … 65 more files in changeset.
Javadoc for `ComponentIdResolveResult`

    • -0
    • +14
    ./BuildableComponentIdResolveResult.java
Polish: metaData -> metadata

    • -2
    • +2
    ./BuildableComponentIdResolveResult.java
    • -1
    • +1
    ./BuildableComponentResolveResult.java
    • -7
    • +7
    ./DefaultBuildableComponentIdResolveResult.java
    • -12
    • +12
    ./DefaultBuildableComponentResolveResult.java
  1. … 8 more files in changeset.
A ComponentState always has a ComponentIdentifier

Previously, `ComponentState` instances in the graph had a `null` identifier until the module metadata was resolved.

We now provide the `ComponentIdentifier` to the `ComponentState` on construction.

    • -0
    • +7
    ./DefaultBuildableComponentResolveResult.java
  1. … 4 more files in changeset.
Fix dependency constraints showing up as 2 different descriptors

Before this fix, whenever a constraint used a custom message, there were 2

separate descriptors in the list of descriptors in the selection reason: one

was `REQUESTED` with the custom message and one `CONSTRAINT`.

After this commit, the custom message is properly attached to the `CONSTRAINT`

descriptor instead. We also make sure that regular constraints do not lead to

an additional "REQUESTED" descriptor being added.

    • -1
    • +2
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 2 more files in changeset.
Rework component selection reason to support composite explanations

This commit changes how `ComponentSelectionReason` works, so that we can save a list of selection

reasons, instead of a single one. This should let us give richer explananations about why a component

was selected. In particular, a component may be selected because another one was rejected, or it

can be selected by a rule **and** by conflict resolution. This last case was handled in an adhoc

manner, it's now a regular case.

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

    • -2
    • +2
    ./BuildableComponentIdResolveResult.java
    • -7
    • +9
    ./DefaultBuildableComponentIdResolveResult.java
  1. … 39 more files in changeset.