UnknownIncrementalAnnotationProcessingIntegrationTest.groovy

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

    • -2
    • +0
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 12 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).

    • -2
    • +0
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.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.

    • -2
    • +0
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.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.

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

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

    • -4
    • +4
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.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
    • +4
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.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
    • +4
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 34 more files in changeset.
Reword logging when changes require rebuild

    • -1
    • +2
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 1 more file in changeset.
Log whether work changes are incremental

    • -0
    • +1
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 3 more files in changeset.
Log whether work changes are incremental

    • -0
    • +1
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 5 more files in changeset.
Address more review feedback

    • -2
    • +2
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 8 more files in changeset.
Use input changes in JavaCompile

    • -1
    • +1
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 7 more files in changeset.
Only consider resource files for change processing

That is we ignore some changes to directories, thus ignoring addition

and modifications of empty packages.

Fixes #8203

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

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

Makes names clearer and reduces potential confusion.

    • -2
    • +2
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.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
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.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
    • +6
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.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>

    • -2
    • +2
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 10 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
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 7 more files in changeset.
Add more test coverage for incremental processing

    • -1
    • +4
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 1 more file 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
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 15 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.

    • -0
    • +54
    ./UnknownIncrementalAnnotationProcessingIntegrationTest.groovy
  1. … 34 more files in changeset.