Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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.
Rename incremental annotation processor types

The documentation refers to "isolated" and "aggregating" processors,

so the types should reflect that change.

    • -0
    • +207
    ./tasks/compile/AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
    • -0
    • +291
    ./tasks/compile/IsolatedIncrementalAnnotationProcessingIntegrationTest.groovy
    • -207
    • +0
    ./tasks/compile/MultipleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
    • -291
    • +0
    ./tasks/compile/SingleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 19 more files in changeset.
Recompile source file when dependency of generated file changes

Otherwise the incremental compiler would delete the generated file,

but not recompile the source file, making the generated file disappear

completely and breaking the code.

    • -0
    • +52
    ./tasks/compile/SingleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 1 more file in changeset.
Make multiple-origin processors incremental

Multiple origin processors can aggregate multiple source

elements into one output element or create warnings/errors

for such combinations of elements. They need to be provided

with all their elements of interest in the next compilation

when any of them has changed.

We handle this with a very simple approach: If a processor

registers itself for "*" (a.k.a all root elements), then we

always do a full recompile. If a processor only registers itself

for specific annotations, then we treat all elements with those

annotations as dirty on every compilation. This means that multiple

origin processors create small non-incremental clusters of code.

    • -6
    • +125
    ./tasks/compile/MultipleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 12 more files in changeset.
Allow aggregating processors to have 0 originating elements

There is no reason to require at least one originating element.

An aggregating processor could be implemented in a way that it

still creates a file even if no sources where present at all.

It's certainly a corner case, but nothing that would break our

infrastructure.

    • -12
    • +0
    ./tasks/compile/MultipleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
    • -1
    • +1
    ./tasks/compile/SingleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 4 more files in changeset.
Add more test coverage for incremental processing

    • -1
    • +22
    ./tasks/compile/SingleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
    • -1
    • +4
    ./tasks/compile/UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
Address review feedback

Added two more tests and did some cosmetic changes.

    • -0
    • +30
    ./tasks/compile/SingleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 4 more files in changeset.
Make single origin processors incremental

Record the origin->generated type mapping from the Filer

API and recompile generated types when their origin changes.

Delete stale .java files in addition to stale .class files.

    • -7
    • +98
    ./tasks/compile/SingleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 25 more files in changeset.
Allow multiple originating elements from the same type

Gradle tracks dependencies among types, not between individual

methods or other members. This means that there is no problem

if a single-origin annotation processor provides multiple

originating elements if they all come from the same type.

    • -1
    • +1
    ./tasks/compile/MultipleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
    • -2
    • +2
    ./tasks/compile/SingleOriginIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 6 more files in changeset.
Recompile when annotation processor path changes

This fixes a corner case where removing the last

annotation processor can leave stale generated files

around. This is because the next compilatin will be

incremental and only react to input files that actually

changed.

This is a highly unlikely case in practice, as removing

an annotation processor that is still in use would usually

break the code anyway. The more important reason to do this

change is that it will be required for incremental annotation

processing to work correctly.

    • -0
    • +21
    ./tasks/compile/UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 15 more files in changeset.