anchor.diff:  
   Both categories have the following limitations:
   
  +* They have to read `CLASS` or `RUNTIME` retention annotations only.
  +    Reading `SOURCE` retention annotations is possible for "isolating" processors on their own. But it will produce incorrect results when a different "aggregating" processor process the same types as the "isolating" processor, so it should not be used.
   * They must generate their files using the link:{javaApi}/javax/annotation/processing/Filer.html[Filer API].
       Writing files any other way will result in silent failures later on, as these files won't be cleaned up correctly.
       If your processor does this, it cannot be incremental.
  
positive.code: include::{snippetsPath}/java/incrementalAnnotationProcessing/groovy/processor/src/main/java/org/gradle/ServiceRegistryProcessor.java[tag=aggregating-annotation-processor]
  ----
  
  "Aggregating" processors have the following limitations:
  
  * They can only read `CLASS` or `RUNTIME` retention annotations
  * They can only read parameter names if the user passes the `-parameters` compiler argument.
  
  Gradle will always reprocess (but not recompile) all annotated files that the processor was registered for.
  
negative.code: include::{snippetsPath}/java/incrementalAnnotationProcessing/groovy/processor/src/main/java/org/gradle/EntityProcessor.java[tag=isolating-annotation-processor]
  ----
  
  "Isolating" processors have the following additional limitations:
  
  * They must make all decisions (code generation, validation messages) for an annotated type based on information reachable from its AST.
      This means you can analyze the types' super-class, method return types, annotations etc., even transitively.
  