subprojects

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Make http server fixture's handle() thread safe

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle()

method behaved flaky - by not doing reading and updating of the 'run'

flag as an atomic operation.

Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

Use the first found dependency artifact for override metadata

Later in the resolution, we already combine all artifacts defined

as 'dependency artifacts' on incoming edges.

If a component does not have metadata, we need at least information

about one artifact early when we look for an artifact (instead of a

metadata file).

Reuse one object for empty ComponentOverrideMetadata

Reuse one object for empty ComponentOverrideMetadata

Reuse one object for empty ComponentOverrideMetadata

Reuse one object for empty ComponentOverrideMetadata

Track first dependency artifact in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where we search for modules

in repositories.

Track first dependency artifact in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where we search for modules

in repositories.

Track first dependency artifact in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where we search for modules

in repositories.

Track first dependency artifact in SelectorState and ModuleSelectors

This information needs to be preserved to make sure that an artifact

that acts as metadata for itself (metadataSources = artifact()) is

found during the early resolution phase where we search for modules

in repositories.

Add integration test for dependency artifacts in multiple declarations

This test reproduces https://github.com/gradle/gradle/issues/10948

and other variations of it.

Add integration test for dependency artifacts in multiple declarations

This test reproduces https://github.com/gradle/gradle/issues/10948

and other variations of it.

Add integration test for dependency artifacts in multiple declarations

This test reproduces https://github.com/gradle/gradle/issues/10948

and other variations of it.

Add integration test for dependency artifacts in multiple declarations

This test reproduces https://github.com/gradle/gradle/issues/10948

and other variations of it.

Add integration test for dependency artifacts in multiple declarations

This test reproduces https://github.com/gradle/gradle/issues/10948

and other variations of it.

Add more synchronization to http server fixture

As stated in the here implemented 'ServerWithExpectations' fixture:

"handlers, as well as failures, need to be thread-safe"

This concrete case was working most of the time since usually there are

not more than one expectations for the same request. But if the

same request is expected several times, and the requests are received

in parallel (as it is the case for metadata download), the handle

method behaved flaky.

Avoid copying an already immutable list

Avoid copying an already immutable list

Avoid copying an already immutable list

Avoid copying an already immutable list

Avoid copying an already immutable list

Use a linked hash set for dependency artifacts

The order can make a difference in repository selection, when

checking if an artifact-only-component containing the artifacts

exists in a repository. In absence of a metadata file, we initially test

for the existence of one artifact to decide if a repository contains

the corresponding artifact-only-component. This is always the first

artifact in the set (which is internally converted into a list).

This change makes sure that the first artifact is always the same

for a build that does not change.

Use a linked hash set for dependency artifacts

The order can make a difference in repository selection, when

checking if an artifact-only-component containing the artifacts

exists in a repository. In absence of a metadata file, we initially test

for the existence of one artifact to decide if a repository contains

the corresponding artifact-only-component. This is always the first

artifact in the set (which is internally converted into a list).

This change makes sure that the first artifact is always the same

for a build that does not change.

Use a linked hash set for dependency artifacts

The order can make a difference in repository selection, when

checking if an artifact-only-component containing the artifacts

exists in a repository. In absence of a metadata file, we initially test

for the existence of one artifact to decide if a repository contains

the corresponding artifact-only-component. This is always the first

artifact in the set (which is internally converted into a list).

This change makes sure that the first artifact is always the same

for a build that does not change.

Use a linked hash set for dependency artifacts

The order can make a difference in repository selection, when

checking if an artifact-only-component containing the artifacts

exists in a repository. In absence of a metadata file, we initially test

for the existence of one artifact to decide if a repository contains

the corresponding artifact-only-component. This is always the first

artifact in the set (which is internally converted into a list).

This change makes sure that the first artifact is always the same

for a build that does not change.

Use a linked hash set for dependency artifacts

The order can make a difference in repository selection, when

checking if an artifact-only-component containing the artifacts

exists in a repository. In absence of a metadata file, we initially test

for the existence of one artifact to decide if a repository contains

the corresponding artifact-only-component. This is always the first

artifact in the set (which is internally converted into a list).

This change makes sure that the first artifact is always the same

for a build that does not change.

Support artifacts with different names in maven module fixture

Such artifacts can actually be addressed by 'dependency artifacts'

through the 'artifact { }' notation inside a dependency declaration;

or in Gradle Module Metadata.