anchor.diff:  * Adding, removing or changing a resource
   * Changing the name of jars or directories in the classpath
   * Renaming a parameter
  - 
  -
  -Compile-avoidance is deactivated if annotation processors are found on the compile classpath, because for annotation processors the implementation details matter. To better separate these concerns, it's recommended to declare annotation processors separately: the api:org.gradle.api.tasks.compile.CompileOptions[] for the api:org.gradle.api.tasks.compile.JavaCompile[] task type define a `annotationProcessorPath` property that can be used to declare annotation processors. It's recommended to use a distinct configuration for annotation processors: 
  +
  +
  +Compile-avoidance is deactivated if annotation processors are found on the compile classpath, because for annotation processors the implementation details matter. To better separate these concerns, it's recommended to declare annotation processors separately: the api:org.gradle.api.tasks.compile.CompileOptions[] for the api:org.gradle.api.tasks.compile.JavaCompile[] task type define a `annotationProcessorPath` property that can be used to declare annotation processors. It's recommended to use a distinct configuration for annotation processors:
   ++++
   <sample xmlns:xi="http://www.w3.org/2001/XInclude" id="annotationProcessing" dir="java/apt" title="Declaring annotation processors">
                   <sourcefile file="build.gradle" snippet="annotation-processing"/>
               </sample>
   ++++
  - 
  +
   
   [[sec:java_test]]
   === Test
  
positive.code: * If a compile task fails due to a compile error, it will do a full compilation again the next time it is invoked.
  * Because of type erasure, the incremental compiler is not able to recognize when a type is only used in a type parameter, and never actually used in the code. For example, imagine that you have the following code: `List&lt;? extends A&gt; list = Lists.newArrayList();` but that no member of `A` is in practice used in the code, then changes to `A` will not trigger recompilation of the class. In practice, this should very rarely be an issue.
  
   
  
  [[sec:java_compile_avoidance]]
  === Compile avoidance
  
  If a dependent project has changed in an https://en.wikipedia.org/wiki/Application_binary_interface[ABI]-compatible way (only its private API has changed), then Java compilation tasks will be up-to-date. This means that if project `A` depends on project `B` and a class in `B` is changed in an ABI-compatible way (typically, changing only the body of a method), then Gradle won't recompile `A`.
  
  Some of the types of changes that do not affect the public API and are ignored: 
  
  * Changing a method body
  * Changing a comment
  
negative.code: This mechanism has been superseded by 'Test Filtering', described above.
  ====
  
  Setting a system property of __taskName.single__ = __testNamePattern__ will only execute tests that match the specified __testNamePattern__. The __taskName__ can be a full multi-project path like “:sub1:sub2:test” or just the task name. The __testNamePattern__ will be used to form an include pattern of “\**/testNamePattern*.class”. If no tests with this pattern can be found, an exception is thrown. This is to shield you from false security. If tests of more than one subproject are executed, the pattern is applied to each subproject. An exception is thrown if no tests can be found for a particular subproject. In such a case you can use the path notation of the pattern, so that the pattern is applied only to the test task of a specific subproject. Alternatively you can specify the fully qualified task name to be executed. You can also specify multiple patterns. Examples:
  
  * `gradle -Dtest.single=ThisUniquelyNamedTest test`
  * `gradle -Dtest.single=a/b/ test`
  * `gradle -DintegTest.single=\*IntegrationTest integTest`
  * `gradle -Dtest.single=:proj1:test:Customer build`
  * `gradle -DintegTest.single=c/d/ :proj1:integTest`
  
  
  [[sec:test_detection]]
  ==== Test detection
  
  The `Test` task detects which classes are test classes by inspecting the compiled test classes. By default it scans all `.class` files. You can set custom includes / excludes, only those classes will be scanned. Depending on the test framework used (JUnit / TestNG) the test class detection uses different criteria.
  
  When using JUnit, we scan for both JUnit 3 and 4 test classes. If any of the following criteria match, the class is considered to be a JUnit test class:
  
  * Class or a super class extends `TestCase` or `GroovyTestCase`
  * Class or a super class is annotated with `@RunWith`
  * Class or a super class contain a method annotated with `@Test`
  
  
  When using TestNG, we scan for methods annotated with `@Test`.
  
  Note that abstract classes are not executed. Gradle also scans up the inheritance tree into jar files on the test classpath.
  
  If you don't want to use test class detection, you can disable it by setting `scanForTestClasses` to false. This will make the test task only use includes / excludes to find test classes. If `scanForTestClasses` is false and no include / exclude patterns are specified, the defaults are “`\**/*Tests.class`”, “`*\*/*Test.class`” and “`*\*/Abstract*.class`” for include and exclude, respectively.
  
  [[test_grouping]]
  ==== Test grouping
  