anchor.diff:  
   Starting with Gradle 2.1, it is possible to compile Java incrementally. See the api:org.gradle.api.tasks.compile.JavaCompile[] task for information on how to enable it.
   
  -Main goals for incremental compilations are: 
  +Main goals for incremental compilations are:
   
   * Avoid wasting time compiling source classes that don't have to be compiled. This means faster builds, especially when a change to a source class or a jar does not incur recompilation of many source classes that depend on the changed input.
   * Change as few output classes as possible. Classes that don't need to be recompiled remain unchanged in the output directory. An example scenario when this is really useful is using JRebel - the fewer output classes are changed the quicker the JVM can use refreshed classes.
  - The incremental compilation at a high level: 
  +
  +The incremental compilation at a high level:
   
   * The detection of the correct set of stale classes is reliable at some expense of speed. The algorithm uses bytecode analysis and deals gracefully with compiler optimizations (inlining of non-private constants), transitive class dependencies, etc. Example: When a class with a public constant changes, we eagerly compile classes that use the same constants to avoid problems with constants inlined by the compiler.
   * To make incremental compilation fast, we cache class analysis results and jar snapshots. The initial incremental compilation can be slower due to the cold caches.
  -  
   
   [[sec:incremental_compilation_known_issues]]
   ==== Known issues
  
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
  