Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove @ToBeFixedForInstantExecution from CachedJavaCompileIntegrationTest

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -2
    • +0
    ./CachedJavaCompileIntegrationTest.groovy
Remove 'release' property (reverts #12648)

A more high level concept for specifying Java versions will

be introduced soon.

    • -77
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 13 more files in changeset.
Remove 'release' property (reverts #12648)

A more high level concept for specifying Java versions will

be introduced soon.

    • -77
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 13 more files in changeset.
Remove `@ToBeFixedForInstantExecution` from `AbstractIncrementalCompileIntegrationTest`

    • -2
    • +0
    ./AbstractIncrementalCompileIntegrationTest.groovy
Remove `@ToBeFixedForInstantExecution` from `BasicJavaCompilerIntegrationSpec`

    • -1
    • +0
    ./BasicJavaCompilerIntegrationSpec.groovy
Use release/targetComp setting of compile task for jvm version attribute

Before the 'release' property was ignored completely.

The' targetCompatiblity' was alwas taken from the extension/convention

and not from the task. Now we have the following setup which corresponds

to how the compile task determines settings for the Java compiler:

- Use the release property of the task

- If that is not set, its conventions is the

release property of the extension

- If that is not set, we take the targetCompatiblity of the task

- If that is not set, its convention is the

targetCompatiblity of the extension/convention

- If that is not set, its convention is the current Java version

    • -0
    • +97
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 7 more files in changeset.
Use release/targetComp setting of compile task for jvm version attribute

Before the 'release' property was ignored completely.

The' targetCompatiblity' was alwas taken from the extension/convention

and not from the task. Now we have the following setup which corresponds

to how the compile task determines settings for the Java compiler:

- Use the release property of the task

- If that is not set, its conventions is the

release property of the extension

- If that is not set, we take the targetCompatiblity of the task

- If that is not set, its convention is the

targetCompatiblity of the extension/convention

- If that is not set, its convention is the current Java version

    • -0
    • +54
    ./BasicJavaCompilerIntegrationSpec.groovy
    • -0
    • +43
    ./InProcessJavaCompilerIntegrationTest.groovy
  1. … 7 more files in changeset.
Use release/targetComp setting of compile task for jvm version attribute

Before the 'release' property was ignored completely.

The' targetCompatiblity' was alwas taken from the extension/convention

and not from the task. Now we have the following setup which corresponds

to how the compile task determines settings for the Java compiler:

- Use the release property of the task

- If that is not set, its conventions is the

release property of the extension

- If that is not set, we take the targetCompatiblity of the task

- If that is not set, its convention is the

targetCompatiblity of the extension/convention

- If that is not set, its convention is the current Java version

    • -0
    • +97
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 7 more files in changeset.
Use release/targetComp setting of compile task for jvm version attribute

Before the 'release' property was ignored completely.

The' targetCompatiblity' was alwas taken from the extension/convention

and not from the task. Now we have the following setup which corresponds

to how the compile task determines settings for the Java compiler:

- Use the release property of the task

- If that is not set, its conventions is the

release property of the extension

- If that is not set, we take the targetCompatiblity of the task

- If that is not set, its convention is the

targetCompatiblity of the extension/convention

- If that is not set, its convention is the current Java version

    • -0
    • +97
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 7 more files in changeset.
Use release/targetComp setting of compile task for jvm version attribute

Before the 'release' property was ignored completely.

The' targetCompatiblity' was always taken from the extension/convention

and not from the task. Now we have the following setup which corresponds

to how the compile task determines settings for the Java compiler:

- Use the release property of the task

- If that is not set, its conventions is the

release property of the extension

- If that is not set, we take the targetCompatiblity of the task

- If that is not set, its convention is the

targetCompatiblity of the extension/convention

- If that is not set, its convention is the current Java version

    • -0
    • +126
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 7 more files in changeset.
Use release/targetComp setting of compile task for jvm version attribute

Before the 'release' property was ignored completely.

The' targetCompatiblity' was alwas taken from the extension/convention

and not from the task. Now we have the following setup which corresponds

to how the compile task determines settings for the Java compiler:

- Use the release property of the task

- If that is not set, its conventions is the

release property of the extension

- If that is not set, we take the targetCompatiblity of the task

- If that is not set, its convention is the

targetCompatiblity of the extension/convention

- If that is not set, its convention is the current Java version

    • -0
    • +97
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 6 more files in changeset.
Add property to configure the `--release` flag (#12648)

A more convenient, and provider-based, method to configure the

`--release` flag in place of using a plain compiler args like

`compilerArgs.addAll(['--release', '...'])`.

    • -0
    • +36
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 9 more files in changeset.
Add property to configure the `--release` flag

A more convenient, and provider-based, method to configure the

`--release` flag in place of using a plain compiler args like

`compilerArgs.addAll(['--release', '...'])`.

    • -0
    • +34
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 9 more files in changeset.
Add property to configure the `--release` flag

A more convenient, and provider-based, method to configure the

`--release` flag in place of using a plain compiler args like

`compilerArgs.addAll(['--release', '...'])`.

    • -0
    • +34
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 9 more files in changeset.
Add property to configure the `--release` flag

A more convenient, and provider-based, method to configure the

`--release` flag in place of using a plain compiler args like

`compilerArgs.addAll(['--release', '...'])`.

    • -0
    • +36
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 9 more files in changeset.
Add property to configure the `--release` flag

A more convenient, and provider-based, method to configure the

`--release` flag in place of using a plain compiler args like

`compilerArgs.addAll(['--release', '...'])`.

    • -0
    • +34
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 9 more files in changeset.
Add property to configure the `--release` flag

A more convenient, and provider-based, method to configure the

`--release` flag in place of using a plain compiler args like

`compilerArgs.addAll(['--release', '...'])`.

    • -0
    • +34
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 16 more files in changeset.
Add property to configure the `--release` flag

A more convenient, and provider-based, method to configure the

`--release` flag in place of using a plain compiler args like

`compilerArgs.addAll(['--release', '...'])`.

    • -0
    • +36
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 9 more files in changeset.
Add property to configure the `--release` flag

A more convenient, and provider-based, method to configure the

`--release` flag in place of using a plain compiler args like

`compilerArgs.addAll(['--release', '...'])`.

    • -0
    • +34
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 9 more files in changeset.
Remove always-true JDK8_OR_LATER test precondition

    • -1
    • +1
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 41 more files in changeset.
Remove IBM JDK test preconditions (#12512)

We do not run any tests against IBM JDK8 in the pipeline.

    • -2
    • +1
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 7 more files in changeset.
Remove IBM JDK test preconditions

We do not run any tests against IBM JDK8 in the pipeline.

    • -2
    • +1
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 7 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

    • -1
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 27 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

    • -1
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 27 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

    • -1
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 27 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

    • -1
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 27 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

    • -1
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 27 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

    • -1
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 27 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

    • -1
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 27 more files in changeset.
Reimplement source to class name mapping for Java

Previously, mapping from source files to class names was done by extracting

the class names from the class files names, which wasn't 100% accurate.

The Groovy incremental compiler, on the other hand, was implemented using

an AST transformation which could extract the class names from the compiler

itself, therefore giving an accurate mapping from class names to source files.

The same is now done for the Java compiler, using a Java compiler plugin.

This fixes several issues where we could not figure out properly what files

to recompile when the name of the class being used in a dependency wasn't

directly related to the source file name.

However, this introduces a problem when the compiler is not a proper JDK

compiler. In particular, if compiling using a "path to compiler", the

plugin cannot be loaded and incremental compilation will fail.

    • -1
    • +3
    ./BasicJavaCompilerIntegrationSpec.groovy
  1. … 27 more files in changeset.