Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Distributed test

  1. … 22 more files in changeset.
Distributed test

  1. … 22 more files in changeset.
Distributed test

  1. … 22 more files in changeset.
Don't rely only project root .git in tests (#13156)

Some of our tests read git repository information, which breaks distributed test.

This commit resolves git information in build, then pass them to tests via system property.

  1. … 16 more files in changeset.
Pass branch and commit id info

  1. … 1 more file in changeset.
Fix git env

  1. … 2 more files in changeset.
Fix git env

  1. … 1 more file in changeset.
Fix git env

  1. … 2 more files in changeset.
Re-enable SrcDistributionIntegrationSpec

Distributed test

  1. … 8 more files in changeset.
Distributed test

  1. … 8 more files in changeset.
Ignore failure

Merge remote-tracking branch 'origin/sg/65/merges/tooling-api'

* origin/sg/65/merges/tooling-api:

Fix flaky failure

Fix test failures due to error message change

Improve error message for disconnected tooling API clients

Use lowercase for initial letter in test method names

Fix bad merge

Do not use a static field for an instance field in GradleConnector

Fix formatting

Update to be released with 6.5

Extend test coverage

Increase maximum allowed tooling api jar size

Remove duplicate lock statement

Remove unnecessary TODO

Mention changes in the release notes

Move disconnect() method to API

Fix test

Remove comments

Shut down executor service when calling disconnect()

Add daemon shutdown functionality to DefaultGradleConnector

  1. … 1 more file in changeset.
Upgrade JUnit version (#12924)

Upgrade JUnit to 4.13, JUnit platform to 5.6.2

  1. … 331 more files in changeset.
Upgrade JUnit

  1. … 330 more files in changeset.
Merge remote-tracking branch 'origin/donat/daemon-shutdown-api'

* origin/donat/daemon-shutdown-api:

Extend test coverage

Increase maximum allowed tooling api jar size

Remove duplicate lock statement

Remove unnecessary TODO

Mention changes in the release notes

Move disconnect() method to API

Fix test

Remove comments

Shut down executor service when calling disconnect()

Add daemon shutdown functionality to DefaultGradleConnector

  1. … 3 more files in changeset.
Add :fileWatching subproject

  1. … 4 more files in changeset.
Add :fileWatching subproject

  1. … 4 more files in changeset.
Add :fileWatching subproject

  1. … 4 more files in changeset.
Add :fileWatching subproject

  1. … 4 more files in changeset.
Fix more

  1. … 89 more files in changeset.
Fix merge conflict

  1. … 7 more files in changeset.
Fix merge conflict

  1. … 7 more files in changeset.
Fix merge conflict

  1. … 7 more files in changeset.
Fix merge conflict

  1. … 7 more files in changeset.
Fix merge conflict

  1. … 7 more files in changeset.
Increase maximum allowed tooling api jar size

Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

  1. … 21 more files in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

  1. … 21 more files in changeset.
Rework how the compiler plugin is loaded

The previous implementation had a performance regression due to the inclusion of `tools.jar`

on the worker classpath. Some classes of the Java compiler were loaded multiple times. To

avoid this, we need to separate the compiler plugin from Gradle itself, so that we can load

it in isolation in the same classloader as the loader which has `tools.jar`.

Therefore, the compiler plugin is restricted to plain Java APIs, and the "communication"

with Gradle, for example the intelligence of relativizing paths or writing the generated

mapping file, is done passing lambdas to the compiler.

Last but not least, this also means that the construction of the incremental compile task

has to be done via reflection (otherwise we would load the task in the wrong classloader).

  1. … 21 more files in changeset.