IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy

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

    • -2
    • +0
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
Fixes for previous commit.

    • -5
    • +0
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 4 more files in changeset.
Slightly improve handling of Jar manifests when loading from the instant execution cache, so that Jar tasks are up-to-date on first load from the instant execution cache when nothing has changed.

    • -5
    • +0
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 18 more files in changeset.
Slightly improve handling of Jar manifests when loading from the instant execution cache, so that Jar tasks are up-to-date on first load from the instant execution cache when nothing has changed.

    • -5
    • +0
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 18 more files in changeset.
Slightly improve handling of Jar manifests when loading from the instant execution cache, so that Jar tasks are up-to-date on first load from the instant execution cache when nothing has changed.

    • -5
    • +0
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 18 more files in changeset.
Fixes for previous commit.

    • -6
    • +0
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 12 more files in changeset.
Fixes for previous commit.

    • -6
    • +2
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 8 more files in changeset.
Fixes for previous commit.

    • -6
    • +2
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 8 more files in changeset.
Model the output directory for source files generated by annotation processors as a `DirectoryProperty` and replace the convention mapping with a convention on the property.

This change means that JavaCompile tasks added by the Java base plugin for a source set will be up-to-date on first load from the instant execution cache, and will generate source files to the correct location when they do happen to run.

The issue was caused because instant execution (intentionally) ignores convention mappings applied to `Provider` types fields. This issue, and others like it, would have been easier to diagnose if this case were treated as an instant execution serialization problem (and reported, etc).

    • -12
    • +2
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 25 more files in changeset.
Model the output directory for source files generated by annotation processors as a `DirectoryProperty` and replace the convention mapping with a convention on the property.

This change means that JavaCompile tasks added by the Java base plugin for a source set will be up-to-date on first load from the instant execution cache, and will generate source files to the correct location when they do happen to run.

    • -12
    • +2
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 25 more files in changeset.
Model the output directory for source files generated by annotation processors as a `DirectoryProperty` and replace the convention mapping with a convention on the property.

This change means that JavaCompile tasks added by the Java base plugin for a source set will be up-to-date on first load from the instant execution cache, and will generate source files to the correct location when they do happen to run.

    • -12
    • +2
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 25 more files in changeset.
Rename @FailsWithInstantExecution to @ToBeFixedForInstantExecution

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

    • -13
    • +13
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 872 more files in changeset.
Annotate integ tests failing with instant execution in :languageJava

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

    • -0
    • +13
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 34 more files in changeset.
Annotate integ tests failing with instant execution in :languageJava

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

    • -0
    • +13
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 34 more files in changeset.
Improve incremental compilation for Java

This patch splits the collected dependencies found in a .class file into "accessible" and "private" dependencies.

* "Accessbile" dependencies are classes that belong to non-private fields, non-private method signatures, class signature ("extends", "implements") etc

* "Private" dependencies are classes that belong to private fields, private methods and classes used in method bodies (i.e. just in "the code")

The TL;DR of the approach is to change the algorithm in `ClassSetAnalysis.getRelevantDependents` to only recurse for "accessible" dependencies.

Goal by example:

Consider classes like

```

class A {

private B b

}

class B {

private C c

}

class C {

}

```

The previous algorithm in `ClassSetAnalysis.getRelevantDependents` would recompile all classes, if `C` was changed. The new algorithm recompiles

just `B` and `C`, because `C` has been changed and `B` uses `C`. But it doesn't recompile `A`, because `A` is not affected by the change. The same

is true, if `C` would have been only used in a method body of `B` or in the signature of a `private` function in `B`.

The algorithm properly handles changes to classes used in the following example:

```

public class SomeClass {

List<Integer> field = new LinkedList<Integer>();

private AccessedFromPrivateField accessedFromPrivateField;

AccessedFromPackagePrivateField someField;

private AccessedFromPrivateMethod accessedFromPrivateMethod() {

return null;

}

public String accessedFromPrivateMethodBody() {

return new AccessedFromPrivateMethodBody().toString();

}

private Set<String> stuff(HashMap<String, String> map) {

System.out.println(new Foo());

return new HashSet<String>();

}

private class Foo {

// Hint: this field won't appear in the ClassAnalysis for SomeClass

public AccessedFromPrivateClassPublicField anotherField;

public String toString() {

return "" + new AccessedFromPrivateClass();

}

}

}

```

Changes the serialization format of `ClassAnalysis` + `DependentsSet`

Signed-off-by: Robert Stupp <snazy@snazy.de>

    • -1
    • +1
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 23 more files in changeset.
Support resource creation in incremental annotation processors

Allow resources to be created by incremental annotation processors using

`Filer#createResource`. Allow resources to be created in the three currently

existing output locations on `StandardLocation`: `SOURCE_OUTPUT`,

`CLASS_OUTPUT`, and `NATIVE_HEADER_OUTPUT`.

A generated resource is uniquely identified by its `Location` and its path

relative to that `Location`. A new type `GeneratedResource` is created to that

effect. Data of that type is then plumbed through the existing annotation

processing infrastructure, ultimately reaching

`IncrementalCompilationInitializer` so that cleaning may be done.

Resolves #4702.

Signed-off-by: Ian Kerins <ianskerins@gmail.com>

    • -15
    • +96
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 36 more files in changeset.
Silence unrecognized annotation processor option during incremental processing

This works by registering an additional annotation processor

matching everything so it's guaranteed to be called, and that

collects all other processors' supported options in its own

supported options. That way, all those options will always be

see by javac as being supported, even when recompiling only

a subset of files that won't trigger some processors.

As a side-effect, this fully works around the underlying javac

issue (https://bugs.openjdk.java.net/browse/JDK-8162455) even

during full recompilations.

Fixes #8128

Signed-off-by: Thomas Broyer <t.broyer@ltgt.net>

    • -0
    • +22
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 3 more files in changeset.
Resolve package cycle

    • -1
    • +1
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 24 more files in changeset.
Reference enum constants from tests

    • -2
    • +4
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 3 more files in changeset.
Only decorate compilation of JavaCompile task

Makes names clearer and reduces potential confusion.

    • -2
    • +2
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 19 more files in changeset.
Report annotation processor type in build operation result

Instead of just reporting whether an annotation processor was

incremental, we now report its type, i.e. aggregating, isolating, or

unknown.

    • -1
    • +1
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 10 more files in changeset.
Report whether annotation processor is incremental

This commit adds an `incremental` property to the result of the build

operation and checks that it’s reported correctly for the different

annotation processor types.

    • -0
    • +15
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 23 more files in changeset.
Set default value to annotationProcessorGeneratedSourcesDirectory

This also fixes the documentation for the options.annotationProcessorPath

default value.

Fixes #4956

Signed-off-by: Thomas Broyer <t.broyer@ltgt.net>

    • -5
    • +5
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 10 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.

    • -18
    • +2
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 9 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
    • +6
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 10 more files in changeset.
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.

    • -16
    • +44
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 11 more files in changeset.
Change int tests to use relevant fixture methods to express their expectations about the build log output.

    • -4
    • +4
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 22 more files in changeset.
Rename isolated annotation processors to "isolating"

To be symmetric with "aggregating".

    • -0
    • +291
    ./IsolatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 16 more files in changeset.