ErrorHandlingModuleComponentRepositoryTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Only do maven artifact discovery for variants that require it

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 11 more files in changeset.
Only do maven artifact discovery for variants that require it

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 12 more files in changeset.
Only do maven artifact discovery for variants that require it

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 11 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 15 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 15 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 15 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 15 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 15 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 15 more files in changeset.
Make selected variant known to artifact resolving

This will allow us to use different resolving strategies depending

on the variant that carries the artifact(s). We need this to allow

modules with variants from mixed origins. For example, a module

with only pom metadata, which carries additional variants added

by component metadata rules.

    • -5
    • +7
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 15 more files in changeset.
Restrict cases where to do HTTP retries

This commit restricts the number of cases where we're going to perform HTTP retries. Instead of any error,

we will now retry when:

- a connection timeout occurs (client or server)

- the server responds an error code between 500 and 600

- response code is a too many requests error

Fixes #7850

    • -26
    • +89
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 4 more files in changeset.
Improve debugging of http retries

When an http request fails during dependency resolution, we now have

more information in the debug logging statement reporting the failure

and the retry.

    • -1
    • +1
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 1 more file 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

    • -6
    • +43
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 10 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.

    • -2
    • +3
    ./ErrorHandlingModuleComponentRepositoryTest.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.

    • -1
    • +1
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 27 more files in changeset.
Rename id accessors for consistency

Use `ComponentIdentifier getId()`

Use `ModuleVersionIdentifier getModuleVersionId()`

    • -2
    • +2
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 67 more files in changeset.
Add a `ModuleDependencyMetadata` subtype

Represents dependency information required for resolving a dependency from a

repository. DependencyMetadata sourced from the DSL is wrapped appropriately,

whereas DependencyMetadata sourced from an external module will have this type

natively.

Provides typed access to `ModuleComponentSelector`, making it easier to remove

uses of `DependencyMetadata.requested`

    • -2
    • +2
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 29 more files in changeset.
Make `ModuleComponentSelector` use `ImmutableVersionConstraint`

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

... and use the immutable version whenever possible.

    • -2
    • +2
    ./ErrorHandlingModuleComponentRepositoryTest.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

    • -1
    • +2
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 93 more files in changeset.
Add blacklister to repository management (#3047)

Fix https://github.com/gradle/gradle/issues/2853

Previous versions of Gradle would fall through to the next repository

if resolution in one repository failed. This may cause potentially

indeterministic resolution result. This PR changes this behaviour

and will explicitly rethrow exceptions which occur in dependency

resolution instead of quietly continue to the next repository.

What's more, this PR introduces a RepositoryBlacklister. Exceptions

thrown during dependency resolution are categoried as follows:

1. Caused by HTTP error status code (other than 2xx/3xx/404)

These exceptions would be considered as "recoverable" since

the server seems still to be able to respond.

2. Caused by other IOException/UncheckedIOException

These exceptions would be considered as "unrecoverable"

and the repository would be blacklisted in the build.

    • -0
    • +201
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 19 more files in changeset.
Do not check other repositories if presence of module cannot be determined

    • -15
    • +15
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 19 more files in changeset.
Introduce HTTP connection and socket timeout

    • -0
    • +237
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 17 more files in changeset.
Revert Http socket/connection timeouts for the release (#2879)

    • -237
    • +0
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 18 more files in changeset.
Do not check other repositories if presence of module cannot be determined

    • -15
    • +15
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 12 more files in changeset.
Defines default HTTP connection and socket timeouts (#2757)

    • -0
    • +237
    ./ErrorHandlingModuleComponentRepositoryTest.groovy
  1. … 18 more files in changeset.