AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fixes for previous commit.

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

    • -7
    • +3
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 8 more files in changeset.
Fixes for previous commit.

    • -7
    • +3
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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).

    • -16
    • +3
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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.

    • -16
    • +3
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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.

    • -16
    • +3
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 25 more files in changeset.
Rename @FailsWithInstantExecution to @ToBeFixedForInstantExecution

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

    • -11
    • +11
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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
    • +11
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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
    • +11
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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>

    • -17
    • +45
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 36 more files in changeset.
Resolve package cycle

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

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

Makes names clearer and reduces potential confusion.

    • -2
    • +2
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.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
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 9 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.

    • -11
    • +34
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 11 more files in changeset.
Fix test after fixture changes

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

Make aggregating annotation processors faster

    • -7
    • +37
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 1 more file in changeset.
Change int tests to use relevant fixture methods to express their expectations about the build log output.

    • -2
    • +2
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 22 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.

    • -7
    • +37
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 27 more files in changeset.
Rename isolated annotation processors to "isolating"

To be symmetric with "aggregating".

    • -1
    • +1
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 16 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
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 22 more files in changeset.
Validate Filer usage of incremental annotaiton processors

This ensures that annotation processors which register themselves

as incremental actually honor their contract. They need to provide

originating elements for every file they generate. Single origin

processors can only provide one such element, multiple origin

processors can provide many. Neither of them are allowed to create

or read resource files, since our incremental compiler only tracks

class changes.

With this validation in place, annotation processor authors can

already start checking their processors for compatibility before

we have even implemented the actual incremental compilation.

This change also fixes some corner cases in our annotation processor

detection, so we never report the same processor twice. This can happen

if a processor is present on the classpath in different versions.

    • -54
    • +0
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 34 more files in changeset.
Detect incremental annotation processors

    • -0
    • +54
    ./AggregatingIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 14 more files in changeset.