Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Prohibit setting `-sourcepath` directly via Java compiler args

This behaviour was deprecated in 4.x. Removing for 5.0.

Fixes #6294

    • -32
    • +5
    ./tasks/compile/JavaCompileIntegrationTest.groovy
  1. … 3 more files in changeset.
Ignore annotation processors on compile classpath

Resolves #6296.

    • -4
    • +4
    ./tasks/compile/JavaAnnotationProcessingIntegrationTest.groovy
  1. … 16 more files in changeset.
Ignore some tests on IBM JDK

Some tests (e.g. JavaFx) are not supported by IBM JDK 8, ignored.

  1. … 2 more files in changeset.
Ignore some tests on IBM JDK

Some tests (e.g. JavaFx) are not supported by IBM JDK 8, ignored.

  1. … 2 more files in changeset.
Raise minimum build JVM version to Java 8

    • -11
    • +11
    ./tasks/compile/JavaCompileJavaVersionIntegrationTest.groovy
  1. … 29 more files in changeset.
Recompile when a resource file changes

We can't tell what annotation processors might be doing with a

resource file, as the processing API does not provide any way

of associating resources with outputs. Therefor the only safe

option for now is doing a full recompile.

We no longer force a full recompile when a processor reads a

resource. We only recompile if the resource changes. This makes

it even easier to make a lot of processors incremental.

    • -0
    • +21
    ./tasks/compile/AbstractIncrementalAnnotationProcessingIntegrationTest.groovy
    • -18
    • +2
    ./tasks/compile/AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
    • -18
    • +2
    ./tasks/compile/IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 7 more files in changeset.
Remove CompileOptions.bootClasspath

#6297

    • -20
    • +0
    ./tasks/compile/JavaCompileIntegrationTest.groovy
  1. … 7 more files in changeset.
Make Lombok work in forked compilers

Lombok (and potentially other processors) access certain compiler

internals to do their magic. While this is not valid according to

the processing spec, we still need to support it unless we want to

annoy a big part of our user base.

    • -1
    • +0
    ./tasks/compile/JavaAnnotationProcessingIntegrationTest.groovy
  1. … 2 more files in changeset.
Add first-class support for Javac's -h option

Add the headerOutputDirectory as a compile option,

track it as an output directory and delete stale headers

when doing incremental compilation.

    • -0
    • +41
    ./tasks/compile/JavaCompileIntegrationTest.groovy
  1. … 20 more files in changeset.
Use external repository mirrors in build (#6094)

We've been bitten by external repository fluctuation for a long time.

This PR makes most of tests use repository mirrors set up by ourselves

via init script and system property.

There're still some tests not switching to mirrors, which would be fixed

in follow-up commits.

  1. … 99 more files in changeset.
Expose deprecation warning messages and stacktraces via build operations (#5881)

Expose deprecation warnings as operation progress events

- introduce split of message, warning and advice

- make deprecation progress events immutable

- rework deprecation handling/messages to support more a richer model

- update build operation progress model

- tweak existing deprecation warnings to match new model

- Add performance test + make stacktrace calculation for build ops lazy

- Always include a trace with FeatureUsage now that its always required

  1. … 65 more files in changeset.
Make incremental compilation the default.

    • -4
    • +0
    ./tasks/compile/AbstractIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 23 more files in changeset.
Delete empty package directories

When all classes of a package have been removed,

the package directory in the output directory

will now be removed as well. This ensures that

the resulting JAR will be byte-for-byte equivalent

to a clean build.

    • -0
    • +24
    ./tasks/compile/JavaCompileIntegrationTest.groovy
  1. … 5 more files in changeset.
Remove unnecessary @LeaksFileHandles and fork = true

These were added to work around file leaks in the

in-processor Java/Groovy compilers, which were fixed

in previous commits. This makes the tests faster and

also makes sure that we will spot any future leaks

that could make our user's life harder.

    • -1
    • +0
    ./tasks/compile/AbstractIncrementalAnnotationProcessingIntegrationTest.groovy
    • -1
    • +6
    ./tasks/compile/IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
    • -5
    • +0
    ./tasks/compile/JavaAnnotationProcessingIntegrationTest.groovy
    • -1
    • +0
    ./tasks/compile/JavaCompileAvoidanceWithBuildCacheServiceIntegrationTest.groovy
  1. … 7 more files in changeset.
Fix annotation processor discovery file leak

On Java 8 and below, the default annotation processor

discovery of javac leaks file handles. This is now fixed

by always using our own discovery, which we had introduced

for incremental annotation processing.

This also uncovered some discrepancies how our compiler worked

with and without incremental compilation. It now behaves consistently.

    • -1
    • +1
    ./tasks/compile/AbstractIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 16 more files in changeset.
Use daemon by default when forking from embedded executor

The Play! integration tests always fork a new process

so that they can cancel it. The embedded executor was

using no-daemon mode when asked for a forking handle.

This is now changed to use a daemon instead, greatly

speeding up the Play! integreation tests in embedded

mode.

I stumbled over a bug in our module registry that made

it impossible to run anything in IntelliJ in embedded

mode that used a type from the "plugins" project.

I suspect that some "requireDistribution" usages might

be just because of this bug. We should definitely check that.

There was also some inconsistency in how the embedded executor

handled jvm args and environment variables when it forked a

process. This went unnoticed because it wasn't using the daemon

and the arguments it was missing were to work around issues in

daemon mode. This is now fixed by extending the daemon executor.

    • -0
    • +10
    ./tasks/compile/JavaCompileJavaVersionIntegrationTest.groovy
  1. … 9 more files in changeset.
Resolve source files later

The cleaning compiler may still remove some of the source files for

some configurations, so we may pass non-existing files to the compiler

which causes the compilation to fail.

See https://github.com/gradle/gradle/issues/5448.

    • -0
    • +29
    ./tasks/compile/JavaAnnotationProcessingIntegrationTest.groovy
  1. … 9 more files in changeset.
Merge pull request #5256 from gradle/oehme/malformed-jars

Remove malformed jar/class deprecation

Make incremental annotation processing lenient

Instead of failing when the incremental contract is violated,

Gradle will now do a full recompilation instead, warning the

user about the violation that caused this.

This should make it much easier and safer to mark certain

processors as incremental. For instance, the MapStruct

processor has a rarely-used feature that generates a resource.

Previously it couldn't have been marked as incremental because

resource generation would have been an error. Now it can be

marked incremental and if a user uses the resource-generating

feature, it'll simply result in full recompilation.

    • -11
    • +34
    ./tasks/compile/AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
    • -16
    • +44
    ./tasks/compile/IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 10 more files in changeset.
Add integration test for empty packages

    • -0
    • +33
    ./tasks/compile/JavaCompileIntegrationTest.groovy
Remove malformed jar/class deprecation

Whether malformed files are valid for a task

is not Gradle's business. Gradle can always

fall back to a more primitive hashing strategy.

The warning is now put into the debug log to

help with the unlikely case of an investigation

into broken JARs causing performance issues.

  1. … 2 more files in changeset.
Ignore unused non-incremental processors

Compilation can be incremental even if there are

non-incremental processors on the processor path

as long as those processors are never used. This

is quite a common scenario since incremental and

non-incremental processors may be packaged up

together or a non-incremental processor may be

accidentally leaked as part of a dependency.

    • -2
    • +14
    ./tasks/compile/UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 7 more files in changeset.
Delete stale generated sources on full recompiles

Fixes https://github.com/gradle/gradle/issues/4935

    • -0
    • +19
    ./tasks/compile/JavaAnnotationProcessingIntegrationTest.groovy
  1. … 13 more files in changeset.
Fix languageJava usages of output test fixtures

    • -2
    • +2
    ./tasks/compile/JavaAnnotationProcessingIntegrationTest.groovy
  1. … 2 more files in changeset.
Fix test after fixture changes

    • -1
    • +1
    ./tasks/compile/AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
Merge pull request #4747 from gradle/oehme/apt/incremental/fast-aggregating

Make aggregating annotation processors faster

    • -3
    • +3
    ./tasks/compile/AbstractIncrementalAnnotationProcessingIntegrationTest.groovy
    • -7
    • +37
    ./tasks/compile/AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
Change int tests to use relevant fixture methods to express their expectations about the build log output.

    • -1
    • +1
    ./tasks/compile/AbstractIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 30 more files in changeset.
Change int tests to use relevant fixture methods to express their expectations about the build log output.

    • -2
    • +2
    ./tasks/compile/AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
    • -4
    • +4
    ./tasks/compile/IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
    • -1
    • +1
    ./tasks/compile/JavaAnnotationProcessingIntegrationTest.groovy
  1. … 19 more files in changeset.
Make aggregating annotation processors faster

Aggregating processors need to reprocess all classes they are

interested in on any change. Until now this was ensured by passing

all their source files to the compiler for recompilation.

However, the Java compiler can run annotation processing on class

files too. So instead of recompiling the (unchanged) source files

we now tell the compiler which classes to reprocess. This adds a

small new limitation for aggregating processors - their annotations

need to have at least CLASS retention to be visible in the class

files. The benefit is much faster compilation.

    • -3
    • +3
    ./tasks/compile/AbstractIncrementalAnnotationProcessingIntegrationTest.groovy
    • -7
    • +37
    ./tasks/compile/AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 26 more files in changeset.
Rename isolated annotation processors to "isolating"

To be symmetric with "aggregating".

    • -1
    • +1
    ./tasks/compile/AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
    • -291
    • +0
    ./tasks/compile/IsolatedIncrementalAnnotationProcessingIntegrationTest.groovy
    • -0
    • +291
    ./tasks/compile/IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 14 more files in changeset.