<commit_before>The Gradle team is pleased to announce Gradle 3.4 RC-1.

There is definitely a Java flavor to this release with many of they key release features focusing on the Java ecosystem.

In a further step in our commitment to continual performance improvement, this release of Gradle introduces **compile-avoidance** for Java as well as significant improvements **incremental compilation** for Java. 

We have made various improvements have been made to the **Jacoco plugin** and **delayed evaluation** can now be used for properties in the `WriteProperties` task.

Source tasks such as `JavaCompile` that are skipped due to nil source inputs will now provide this feedback, rather that just reporting as being up to date.

We have also fixed a previous oversight in the `compileOnly` configuration to limit dependencies to those only required for compilation.

Finally, we have also added a command-line option for **Gradle build scan**, eliminating the need for passing a system property and tasks

Enjoy the new version and let us know what you think!

## New and noteworthy

Here are the new features introduced in this Gradle release.

<!--
IMPORTANT: if this is a patch release, ensure that a prominent link is included in the foreword to all releases of the same minor stream.
Add-->

<!--
### Example new and noteworthy
-->

### Task for enforcing JaCoCo code coverage metrics

Gradle introduces a feature for the JaCoCo plugin strongly requested by the community: enforcing code coverage metrics. The JaCoCo plugin now provides a new task of type `JacocoCoverageVerification` enabling the user to define and enforce violation rules. Coverage verification does not automatically run as part of the `check` task. Please see the relevant user guide section on the “[JaCoCo plugin](userguide/jacoco_plugin.html#sec:jacoco_report_violation_rules)” for more information.
 
    tasks.withType(JacocoCoverageVerification) {
        violationRules {
            rule {
                limit {
                    minimum = 0.5
                }
            }
        }
    }

### Compile-avoidance for Java

This version of Gradle introduces a new mechanism for up-to-date checking of Java compilation tasks, which is now sensitive to public API changes only: if a
dependent project changed in an ABI-compatible way (only its private API has changed), then the task is going to be up-to-date.
It means, for example, that if project `A` depends on project `B` and that a class in `B` is changed in an ABI-compatible way
(typically, changing only the body of a method), then we won't recompile `A`. Even finer-grained compile-avoidance can be achieved by
enabling incremental compilation, as explained below.
    
### Faster Java incremental compilation
    
The Java incremental compiler has been significantly improved. In particular, it's now capable of dealing with constants in a smarter way. Due to the way constants are inlined by the Java compiler, previsous Gradle releases have always taken the conservative approach and recompiled everything. Now it will avoid recompiling:

- if a constant is found in a dependency, but that constant isn't used in your code
- if a constant is changed in a dependency, but that constant wasn't used in your code
- if a change is made in a class containing a constant, but the value of the constant didn't change

The new incremental compiler will recompile only the small subset of potentially affected classes.

In addition, the incremental compiler is now backed by in-memory caches, avoiding a lot of disk I/O which slowed it down.

### Annotation processor path for Java compilation

The `CompileOptions` for the `JavaCompile` task type now defines a `annotationProcessorPath` property, which allows you to specify the annotation processor path to use for compilation. This path is treated as an input for the compilation task, meaning that the annotation processor path is built as required, and the contents is considered for incremental build.

### Gradle removes source set output directories on upgrade

Gradle keeps information about each task's inputs and outputs in your project's `.gradle` directory. If this information is lost or cannot be read, your build directory can be in an inconsistent state. Stale files from previous builds may be left behind because nothing tries to remove them. [GitHub issue #1018](https://github.com/gradle/gradle/issues/1018) is an example of the problems this can cause.

Gradle now removes the output directories for source sets when this situation is detected. This new behavior is only applies when a project uses the `java` plugin.
<commit_msg>Mention `@CompileClasspath` in release notes.<commit_after>The Gradle team is pleased to announce Gradle 3.4 RC-1.

There is definitely a Java flavor to this release with many of they key release features focusing on the Java ecosystem.

In a further step in our commitment to continual performance improvement, this release of Gradle introduces **compile-avoidance** for Java as well as significant improvements **incremental compilation** for Java. 

We have made various improvements have been made to the **Jacoco plugin** and **delayed evaluation** can now be used for properties in the `WriteProperties` task.

Source tasks such as `JavaCompile` that are skipped due to nil source inputs will now provide this feedback, rather that just reporting as being up to date.

We have also fixed a previous oversight in the `compileOnly` configuration to limit dependencies to those only required for compilation.

Finally, we have also added a command-line option for **Gradle build scan**, eliminating the need for passing a system property and tasks

Enjoy the new version and let us know what you think!

## New and noteworthy

Here are the new features introduced in this Gradle release.

<!--
IMPORTANT: if this is a patch release, ensure that a prominent link is included in the foreword to all releases of the same minor stream.
Add-->

<!--
### Example new and noteworthy
-->

### Task for enforcing JaCoCo code coverage metrics

Gradle introduces a feature for the JaCoCo plugin strongly requested by the community: enforcing code coverage metrics. The JaCoCo plugin now provides a new task of type `JacocoCoverageVerification` enabling the user to define and enforce violation rules. Coverage verification does not automatically run as part of the `check` task. Please see the relevant user guide section on the “[JaCoCo plugin](userguide/jacoco_plugin.html#sec:jacoco_report_violation_rules)” for more information.
 
    tasks.withType(JacocoCoverageVerification) {
        violationRules {
            rule {
                limit {
                    minimum = 0.5
                }
            }
        }
    }

### Compile-avoidance for Java

This version of Gradle introduces a new mechanism for up-to-date checking of Java compilation tasks, which is now sensitive to public API changes only: if a
dependent project changed in an ABI-compatible way (only its private API has changed), then the task is going to be up-to-date.
It means, for example, that if project `A` depends on project `B` and that a class in `B` is changed in an ABI-compatible way
(typically, changing only the body of a method), then we won't recompile `A`. Even finer-grained compile-avoidance can be achieved by
enabling incremental compilation, as explained below.

### `@CompileClasspath` annotation for task properties

Java compile avoidance is implemented using a new [`@CompileClasspath`](javadoc/org/gradle/api/tasks/CompileClasspath.html) annotation that can be attached to a task property, similar to `@InputFiles` or `@Classpath`. This annotation is also available for use in your own tasks as well, for those tasks that take a Java compile classpath. For example, you make have a task type that performs static analysis using the signatures of classes. You can use the `@CompileClasspath` annotation for this task instead of `@InputFiles` or `@Classpath`, to avoid running the task when the class signatures have not changed.
    
### Faster Java incremental compilation
    
The Java incremental compiler has been significantly improved. In particular, it's now capable of dealing with constants in a smarter way. Due to the way constants are inlined by the Java compiler, previsous Gradle releases have always taken the conservative approach and recompiled everything. Now it will avoid recompiling:

- if a constant is found in a dependency, but that constant isn't used in your code
- if a constant is changed in a dependency, but that constant wasn't used in your code
- if a change is made in a class containing a constant, but the value of the constant didn't change

The new incremental compiler will recompile only the small subset of potentially affected classes.

In addition, the incremental compiler is now backed by in-memory caches, avoiding a lot of disk I/O which slowed it down.

### Annotation processor path for Java compilation

The `CompileOptions` for the `JavaCompile` task type now defines a `annotationProcessorPath` property, which allows you to specify the annotation processor path to use for compilation. This path is treated as an input for the compilation task, meaning that the annotation processor path is built as required, and the contents is considered for incremental build.

### Gradle removes source set output directories on upgrade

Gradle keeps information about each task's inputs and outputs in your project's `.gradle` directory. If this information is lost or cannot be read, your build directory can be in an inconsistent state. Stale files from previous builds may be left behind because nothing tries to remove them. [GitHub issue #1018](https://github.com/gradle/gradle/issues/1018) is an example of the problems this can cause.

Gradle now removes the output directories for source sets when this situation is detected. This new behavior is only applies when a project uses the `java` plugin.

{'fraction_non_alphanumeric': 0.04603222255578905, 'fraction_numerical': 0.0026018212748924246, 'mean_word_length': 4.226987447698745, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3389288', 'n_tokens_mistral': 2403, 'n_tokens_neox': 2240, 'n_words': 1451}