subprojects

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

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.

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.

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.

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.

Mark `KotlinBuildScript` as `@since 6.0` to silence binary compatibility errors

Mark `KotlinBuildScript` as `@since 6.0` to silence binary compatibility errors

Mark `KotlinBuildScript` as `@since 6.0` to silence binary compatibility errors

Mark `KotlinBuildScript` as `@since 6.0` to silence binary compatibility errors

Report script diagnostics to the host

Report script diagnostics to the host

Report script diagnostics to the host

Report script diagnostics to the host

Add a `add-plugin` CLI option

This commit introduces a new CLI flag, `--add-plugin`, which allows adding a plugin to a build

directly from the command line. The main advantage of this is that there's no need to have a

build file to be able to download an apply a plugin.

There are different use cases for this, but mainly, this is about _bootstraping_ plugins.

For example, the vert.x team could publish a plugin which generates a templated Gradle build.

All the user would have to do would be something like:

`gradle --add-plugin com.vertx.bootstrap:1.5`

and then the plugin would take care of generating a build.

Another use case is to add diagnostics (build scans is an example of this but there's already

a built-in mechanism, --scan, to do this).

This spike is _compatible with included builds_, meaning that you can bootstrap with

a plugin currently in development using `--include-build`.

Use the dependency artifacts of all selectors 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 also need to consider all

this information early when we look for an artifact (instead of a

metadata file).

Reuse one object for empty ComponentOverrideMetadata

Collect all dependency artifacts 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 er search for modules

in repositories.

Remove private 'firstSeenDependency' field

This is just a shortcut to a final filed in 'dependencyState'.

Sometimes it was used and sometimes 'dependencyState.getDepenedency()'

was used which is always the same value.

This makes this complex code a bit easier to comprehend.

Remove private 'firstSeenDependency' field

This is just a shortcut to a final filed in 'dependencyState'.

Sometimes it was used and sometimes 'dependencyState.getDepenedency()'

was used which is always the same value.

This makes this complex code a bit easier to comprehend.