Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
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.

Add integration test coverage for repository blacklisting on timeout

Only blacklist a repository on connection timeout failures

Remove more duplicated plugin resolution integration tests

Plugin version validation for artifact repositories already covered in

unit tests.

Duplicated test for simple resolution failure.

Naming repositories is already largely covered.

Make toLowerCamel more efficient

This method was constructing an upper camel

String, only to take it apart again and lower

case it. This change makes both methods share

a common implementation that avoids intermediate


Make task creation by Map cheaper

Task creation by map is used when the user types

the following in the DSL:


task foo(type:Bar) {}


It was always creating two intermediate maps,

which were only necessary for the case when

mandatory arguments were missing or when the

obscure `replace` flag was used. This change

avoids the creation of those maps when possible.

Apply a default location for the import library on `LinkSharedLibrary` based on the binary file location.

Fail attempts to publish invalid module metadata

When the artifacts declared in a component are modified for publishing (name/classifier/extension),

then the Maven publication no longer represents the underlying java component.

Instead of publishing incorrect metadata, we fail any attempt to publish the module metadata.

In the long term, we will likely prevent any modification of artifacts added from a component.

Instead, we will make it easier to modify the component(s) produced by a project, allowing the published

metadata to accurately reflect the local component metadata.

Fixes #3389

Update to Android Gradle Plugin 3.0.0 and other newer libraries.

    • -6
    • +7
Create convention mapping lazily

If the convention mapping is not used, there

is no need to create the rather heavyweight


Provide opt-in to publish _all_ software components with module metadata

Publish war component to module metadata

- Don't publish a usage attribute, as there is only a single variant

Make task comparison cheaper

Tasks are kept in a TreeSet and thus need

to be cheap to compare. This change reduces

the amount of object allocations when comparing


Make task dependencies cheaper

Every task depends on its own inputs. Until

now this was modeled by adding these inputs

to the set of task dependencies. This forces

creation of a set even when this will be the

only entry. It also means that the user can

overwrite it and create a task which no longer

depends on its own inputs.

This change introduces a specialized dependency

object that is aware of the task's inputs. This

avoids unnecessary garbage and makes sure that

the user cannot overwrite it.

Polish some maven-publish tests

Fix published file names for native and java publishing

Artifacts from native components are published with a reference to the

original file name, whereas java components are published using the Maven

standard: {artifactId}-{version}-{classifier}.{extension}

The native plugins now explicitly opt-out of this standard behaviour.

Remove maven assumption from module file generator

The ModuleMetadataFileGenerator now asks the backing publication for

the published name and url for each `PublishArtifact`.

Do not persist requested version in lock file

Ignore flaky test (#3375)

Ignore flaky test for now

Changed the Visual C++ toolchain to honor the import library location specified for a `LinkSharedLibrary` task.

Fix tests

Extract common expectations for artifact publish

Define an import library output location for linking a shared library only when the toolchain doing the linking will produce an import library.

Rename XcTestFinderFixture to use XCTest naming convention

Revert code that fails build upon first unexpected HTTP resolve error

Remove debugging statements

Remove debugging statements

Buffer a line `XcTestScaper`

Buffer a line `XcTestScaper`

Added a `LinkSharedLibrary.importLibrary` to make explicit the fact that the link task can produce an import library file in addition to the runtime library file.