Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename VirtualFileSystem -> FileSystemAccess

    • -3
    • +3
    ./JavaLanguagePluginServiceRegistry.java
  1. … 53 more files in changeset.
Revert "Move JavaCompilerFactory and dependencies to build tree scope"

This reverts commit e251e847366ae158b8ee9ed68bee8b058be50795.

    • -9
    • +3
    ./JavaLanguagePluginServiceRegistry.java
    • -10
    • +4
    ./JavaToolChainServiceRegistry.java
  1. … 4 more files in changeset.
Move JavaCompilerFactory and dependencies to build tree scope

    • -3
    • +9
    ./JavaLanguagePluginServiceRegistry.java
    • -4
    • +10
    ./JavaToolChainServiceRegistry.java
  1. … 4 more files in changeset.
Use real compiler factory for toolchain-based compiler

  1. … 13 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.
Move JavaModuleDetector service to build session scope

This makes modular classpath handling available to more Gradle

infrastructure which itself runs on the JVM. In particular

the execution service (project.javaexec {}) can support running

modules through this.

    • -6
    • +0
    ./JavaLanguagePluginServiceRegistry.java
  1. … 10 more files in changeset.
Add JavaModuleDetector service

A service that analyses JAR files, class and source folders to

determine if they represent a Java module. It caches the result

of the analysis of jar and class files.

It has as similar structure as AnnotationProcessorDetector.

    • -0
    • +6
    ./JavaLanguagePluginServiceRegistry.java
  1. … 3 more files in changeset.
Replace several usages of direct `FileCollection` implementation instantiation with a factory method. Attempt to use the public API when the usage lives in a plugin.

  1. … 20 more files in changeset.
Move some classes out of 'launcher' project to 'buildEvents'.

    • -2
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 125 more files in changeset.
More Java 8 changes

    • -11
    • +3
    ./JavaLanguagePluginServiceRegistry.java
  1. … 2 more files in changeset.
Replace remaining usages of FileSystemSnapshotter

    • -3
    • +3
    ./JavaLanguagePluginServiceRegistry.java
  1. … 22 more files in changeset.
Use isolated parameters for all worker isolation modes

  1. … 44 more files in changeset.
Wrap the patternSet

Instead of using a strategy.

    • -2
    • +1
    ./JavaLanguagePluginServiceRegistry.java
  1. … 37 more files in changeset.
Do not use PatternSet in snapshots package

Use a pluggable type instead.

    • -1
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 43 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 18 more files in changeset.
Use SLF4J Logger in more places

Use only an SLF4J Logger instead of the Gradle Logger in places where it is enough. This is going to make this code more easy to reuse as it doesn't depend on `:logging` anymore.

    • -2
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 29 more files in changeset.
Introduce an internal factory to create `JavaForkOptions`, to encapsulate the service(s) needed to create instances of this type and decouple clients from this detail. This could/should move to `ObjectFactory` or some other public factory type.

  1. … 43 more files in changeset.
Report dependencies of transform operations

    • -3
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 27 more files in changeset.
Report TAPI progress events for work items

This commit introduces a new `OperationType.WORK_ITEM` and adds specific

`ProgressEvent` implementations. For backwards compatibility, if the

new OperationType is not requested, but `OperationType.GENERIC` is, it

will be reported as a generic build operation.

    • -1
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 42 more files in changeset.
Restore forward compatibility

- Remove added method from `InternalTaskResult`

- Rename `OperationResultDecoratorFactory` to

`OperationResultPostProcessor`

    • -4
    • +4
    ./JavaLanguagePluginServiceRegistry.java
  1. … 16 more files in changeset.
Report annotation processor details to TAPI progress listeners

This commit adds the `JavaCompileTaskSuccessResult` subinterface of

`TaskSuccessResult` which is reported as part of `TaskFinishEvents`.

In order to not add dependencies from :toolingApiBuilder to

:languageJava a new `OperationResultDecoratorFactory` interface is

introduced. It allows to invert the control flow so that plugins can

add additional information by decorating `OperationResults`.

    • -0
    • +32
    ./JavaLanguagePluginServiceRegistry.java
  1. … 22 more files in changeset.
Report annotation processor execution time

In order to track time spent by annotation processors, invocations of

compilers in `JavaCompile` and `GroovyCompile` are now wrapped in build

operations that report the execution time per fully-qualified annotation

processor class name in their result.

  1. … 22 more files in changeset.
Always use configured annotationProcessorPath

- Don't use an empty path for `-proc:none` because it is also used by

compiler plugins

- Don't support setting it to `null` anymore.

Resolves #6573.

    • -6
    • +0
    ./JavaLanguagePluginServiceRegistry.java
  1. … 11 more files in changeset.
Ignore annotation processors on compile classpath

Resolves #6296.

    • -2
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 17 more files in changeset.
Move snapshotting files to own package

    • -1
    • +1
    ./JavaLanguagePluginServiceRegistry.java
  1. … 134 more files in changeset.
Remove duplicate class analysis from memory

We no longer store the class analysis of a compile task's

output in that compile tasks's own cache. Instead, we compute

it right before we need it when the next compilation starts.

This removes a lot of unnecessary memory pressure, because no

one else was reusing that state.

It would be even better if we could reuse the analysis that

downstream tasks did on that classes directory (which is an input

for them). To do that we'd need to ensure consistent hashing strategies

between the two.

    • -2
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 16 more files in changeset.
Reuse snapshots of class directories on classpath

Up until now the incremental compiler would only reuse JAR

snapshots. The incremental analysis of class directories on

the classpath was inlined into the incremental analysis of the

task's output. This mean that the analysis was duplicated for

every compile task that used another task's classes folder as

an input.

This has been fixed and class directories are now treated just

like jars. This significantly reduces long term heap usage of the

incremental compiler.

    • -2
    • +3
    ./JavaLanguagePluginServiceRegistry.java
  1. … 13 more files in changeset.
Restore binary compatibility with old Gradle plugins

    • -2
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 6 more files in changeset.
Intern type names in incremental compile caches

Many types will appear again and again as a dependency

to another one. Each of those appearances would result

in an additional String until now. After this fix, each

class name will appear exactly once in the cache.

    • -2
    • +3
    ./JavaLanguagePluginServiceRegistry.java
  1. … 4 more files in changeset.
Cache jar snapshots for immutable files in user home

The jar analysis for incremental compilation can be costly.

Up until now it was always kept in the project directory,

which is lost on clean checkouts on CI.

For immutable files (e.g. external dependencies, gradleApi()),

it is now kept in the user home where reuse is more likely.

    • -2
    • +2
    ./JavaLanguagePluginServiceRegistry.java
  1. … 15 more files in changeset.