MavenLocalRepoResolveIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename @FailsWithInstantExecution to @ToBeFixedForInstantExecution

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

    • -5
    • +5
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 872 more files in changeset.
Merge branch 'master' into eskatos/ie/instantIntegTest-enable

    • -0
    • +30
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 8 more files in changeset.
Add Maven local version listing test

Issue #11321

    • -0
    • +30
    ./MavenLocalRepoResolveIntegrationTest.groovy
Add Maven local version listing test

Issue #11321

    • -0
    • +30
    ./MavenLocalRepoResolveIntegrationTest.groovy
Annotate integ tests failing with instant execution in :dependencyManagement

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

    • -0
    • +5
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 93 more files in changeset.
Annotate integ tests failing with instant execution in :dependencyManagement

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

    • -0
    • +5
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 93 more files in changeset.
Annotate integ tests failing with instant execution in :dependencyManagement

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

    • -0
    • +5
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 93 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

    • -0
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 12 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

    • -0
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 6 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

    • -0
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 12 more files in changeset.
Improve error message when build fails because of missing metadata

Gradle 6.0 removed the "artifact" metadata source by default.

This means that if a module is published _only_ with an artifact,

previous version of Gradle would find it, but 6.0 would fail with

a module missing exception.

The problem is that it's hard to realize that the issue comes

from the change of this default artifact sources.

This commit tries to improve the situation by recognizing that

a failure is related to not finding metadata, and in this case

would suggest that if the metadata is missing, it is still

possible that the jar is present.

The drawback of this approach is that we're unsure: if, for

some reason, the module is _really_ absent, then we gave a

wrong advice. This means, in particular, in case of wrong

coordinates.

    • -0
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 12 more files in changeset.
Adjust tests and samples to new metadata sources defaults

    • -1
    • +0
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 95 more files in changeset.
wip - fix more tests

    • -1
    • +0
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 46 more files in changeset.
wip - fix more tests

    • -1
    • +0
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 45 more files in changeset.
wip - fix more tests

    • -1
    • +0
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 46 more files in changeset.
Add configuration capabilities to Maven local repo

Some of the configuration capabilities were not available for maven

local repository.

This change adds the ability to configure this repository, including

the content filtering aspect.

Fixes #8191

    • -1
    • +5
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 3 more files in changeset.
Add test precondition for tests that rely on working dir modification

    • -1
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 6 more files in changeset.
Add test precondition for tests that rely on working dir modification

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

    • -2
    • +2
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 37 more files in changeset.
Only abort repository lookups on critical resolution failure

Gradle 4.3 introduced an improvement where an error in resolving a module from

one repository would prevent Gradle from searching for that same module in

subsequent repositories (see #2853).

However, the change to abort searching repositories on _all_ unrecognised errors

proved to be too aggressive. With this change, only repository timeout errors

will prevent Gradle from searching for a module in a subsequent repository.

These timeout errors are considered 'critical' and will blacklist the repository

and abort resolution for that module.

In a future release of Gradle, it is likely that we will expand the set of resolution

failures that we consider 'critical' to include server errors (HTTP 500) and the

like. This commit keeps the set small to miminize impact on the 4.3.1 release.

    • -26
    • +0
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 9 more files in changeset.
Revert code that fails build upon first unexpected HTTP resolve error

    • -1
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 6 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
    • +26
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 19 more files in changeset.
Disable remaining failing tests on Java9

    • -0
    • +3
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 3 more files in changeset.
Avoid launching an external process to locate mavenLocal repo

To determine the location of the local maven repo, Gradle parses these values

from the Maven settings files. Using Maven's `DefaultSettingsBuilder`

to parse the Settings files involves quite a lot of additional processing

including spawning a new process to determine environment variables.

This change hooks directly into the Maven `SettingsReader` read settings files

bypassing much of the work performed by `DefaultSettingsBuilder`.

    • -3
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 4 more files in changeset.
Avoid launching an external process to locate mavenLocal repo

To determine the location of the local maven repo, Gradle parses these values

from the Maven settings files. Using Maven's `DefaultSettingsBuilder`

to parse the Settings files involves quite a lot of additional processing

including spawning a new process to determine environment variables.

This change hooks directly into the Maven `SettingsReader` read settings files

bypassing much of the work performed by `DefaultSettingsBuilder`.

    • -3
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 4 more files in changeset.
make tests explicit using m2

+review REVIEW-5724

    • -0
    • +1
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 20 more files in changeset.
check that ~/.m2 repository not touched during integration tests

+review REVIEW-5724

    • -19
    • +19
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 18 more files in changeset.
Some test coverage to reporting locations when we can't resolve something.

    • -1
    • +3
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 6 more files in changeset.
Renamed subprojects/core-impl to subprojects/dependency-management.

    • -0
    • +360
    ./MavenLocalRepoResolveIntegrationTest.groovy
  1. … 1384 more files in changeset.