language-groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[WiP] Explicitly declare different Gradle distributions for testing

  1. … 123 more files in changeset.
[WiP] Explicitly declare different Gradle distributions for testing

  1. … 122 more files in changeset.
Remove runtime only dependencies to :runtimeApiInfo and :apiMetadata

These are in the core of the Gradle distribution and should always

be available at runtime.

  1. … 67 more files in changeset.
Convert buildSrc to included build and precompile shared code quality plugins

  1. … 886 more files in changeset.
Address compiler warnings in 'language-groovy' subproject

Address compiler warnings in 'language-groovy' subproject

Address compiler warnings in 'language-groovy' subproject

Activate 'strict-compile' for all subprojects

  1. … 150 more files in changeset.
Apply the 'classycle' plugin consistently to all projects (#12849)

Existing cycles are now explicitly excluded in the corresponding

build scripts and are thus more visible. They may or may not be

improved on when working on the corresponding project.

  1. … 90 more files in changeset.
Apply the 'classycle' plugin consistently to all projects

Existing cycles are now explicitly excluded in the corresponding

build scripts and are thus more visible. They may or may not be

improved on when working on the corresponding project.

  1. … 90 more files in changeset.
Apply the 'classycle' plugin consistently to all projects

Existing cycles are now explicitly excluded in the corresponding

build scripts and are thus more visible. They may or may not be

improved on when working on the corresponding project.

  1. … 90 more files in changeset.
Use jdk11 instead of jdk9 in tests

  1. … 1 more file in changeset.
Use jdk11 instead of jdk9 in tests

  1. … 1 more file in changeset.
Debug out to test

Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 142 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 141 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 more files in changeset.
Clean up subproject grouping in gradle build

  1. … 143 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. … 20 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. … 20 more files in changeset.