<commit_before>The Gradle team is pleased to bring you Gradle 2.11. This release delivers significant improvements to the new [software model](userguide/software_model.html), together with improvements to IDE integration and continuous build.

The software model is the future of Gradle. The core software model is the basis of the native language and Play framework support in Gradle, and we are working intensively to bring full Java support. With this release, the new Java plugins support testing with JUnit and do a better job in compile avoidance. As well as developing our Java support, we continue to invest in the software model infrastructure, so support for developing any plugin with the new software model also got better.

Existing Java projects also benefit from Gradle 2.11. Improved IDE integration means that developing a Gradle project in IntelliJ IDEA or Eclipse is even better, with fewer tweaks to the IDE configuration required. These improvements encompass both the generated project files and the [Tooling API](userguide/embedding.html) used by IDEs to import Gradle projects.

By detecting changes that occur during build execution, [Continuous build](userguide/continuous_build.html) has become more dependable. We encourage users to try out this cool feature, which can really enhance the development experience with Gradle.

No Gradle release would be complete without contributions from the wonderful Gradle community. In Gradle 2.11, these contributions include:

- Controlling TestNG execution order with the [Java plugin](userguide/java_plugin.html).
- Specifying different test frameworks for a generated Java project using the [Build Init plugin](userguide/build_init_plugin.html).
- Specifying the Java default imports for a Twirl source set when developing with the [Play plugin](userguide/play_plugin.html).
- Publishing 'exclude' information to Ivy files using the [ivy-publish plugin](userguide/publishing_ivy.html).

The full list of contributions is below.

## New and noteworthy

Here are the new features introduced in this Gradle release.

### Better support for developing plugins with the software model

#### Plugins can use managed types for custom source set types

The `LanguageSourceSet` type can now be extended via `@Managed` subtypes, allowing for declaration of `@Managed` source sets without having to provide a default implementation.

Example:

    @Managed
    interface MarkdownSourceSet extends LanguageSourceSet {
        boolean isGenerateIndex()
        void setGenerateIndex(boolean generateIndex)
        boolean isSmartQuotes()
        void setSmartQuotes(boolean smartQuotes)
    }
    class RegisterMarkdown extends RuleSource {
        @LanguageType
        void registerMarkdown(LanguageTypeBuilder<MarkdownSourceSet> builder) {
            builder.setLanguageName("Markdown")
        }
    }
    apply plugin: 'language-base'
    apply plugin: RegisterMarkdown

    model {
        md(MarkdownSourceSet) {
            generateIndex = true
        }
    }

#### A `@ComponentBinaries` rule can create binaries for any `ComponentSpec` instance

The `@ComponentBinaries` annotation can now be used to create binaries for any component type, regardless of its enclosing container. It means that it can be used to define binaries for components in `components`, like it used to, but also for those defined in `testSuites`, or any custom `ComponentSpec` container.

### Improved building and testing Java libraries with the Java software model

#### Testing support

The Java software model now supports declaring a JUnit test suite as a software component, both as a standalone component or with a component under test. More information about declaring test suites can be found in the [userguide](userguide/java_software.html).

In addition, the changes in the software model infrastructure should make it easy to add support for new test frameworks.

#### Better compile avoidance

This version of Gradle further optimizes on avoiding recompiling consuming libraries after non-ABI breaking changes. Since 2.9, if a library declares an API, Gradle creates a "[stubbed API jar](userguide/java_software.html)". This enables avoiding recompiling any consuming library if the application binary interface (ABI) of the library doesn't change. This version of Gradle extends this functionality to libraries that don't declare their APIs, speeding up builds with incremental changes in most Java projects, small or large. In particular, a library `A` that depend on a library `B` will not need to be recompiled in the following cases:

- a private method is added to `B`
- a method body is changed in `B`
- order of methods is changed in `B`

This feature only works for local libraries, not external dependencies. More information about compile avoidance can be found in the [userguide](userguide/java_software.html).

### Enhanced support for developing Java projects in IntelliJ IDEA and Eclipse

Gradle supports IDE-centric development via both generated project files and direct IDE import using the Gradle Tooling API.

This release improves on this support for all Java projects built with Gradle, allowing the IDE view of a project to more closely model the Gradle configuration. Improvements to generated project files are available to try out immediately, while improvements to direct IDE import will require updates to IntelliJ IDEA and Buildship (Gradle support for Eclipse).

#### Generated IDEA files include correct module and project Java language level

The Gradle 'idea' plugin generates configuration files for a Gradle build to be opened and developed in IntelliJ IDEA. Previous versions of Gradle only considered the <a href="dsl/org.gradle.api.Project.html#org.gradle.api.Project:sourceCompatibility">`sourceCompatibility`</a> setting on the _root_ project to determine the 'IDEA Language Level': this setting on any subprojects was not considered.

This behavior has been improved, so that the generated IDEA project will have a 'Language Level' matching the highest `sourceCompatibility` value for all imported subprojects. For a multi-project Gradle build that contains a mix of `sourceCompatibility` values, the generated IDEA module for a sub-project will include an override for the appropriate 'Language Level' where it does not match that of the overall generated IDEA project.

If a Gradle build script uses the DSL to explicitly specify `idea.project.languageLevel`, the `sourceCompatibility` level is _not_ taken into account. In this case only the generated IDEA project will contain a value for 'Language Level', and no module-specific overrides will be generated.

The generated values for 'Language Level' are used when creating the `.ipr` and `.iml` files for a Gradle project, as well as to populate the Tooling API model that is used by IntelliJ IDEA on Gradle project import (see below).

#### Tooling API provides Java language settings for IntelliJ IDEA

The Tooling API exposes `IdeaProject` and the `IdeaModule` models that are used when importing a Gradle build into IntelliJ IDEA. These models not include information on the Java language settings that represent the Gradle configuration for an imported build, and should allow an imported Gradle project in the IDE to more closely match the build configuration.

Java language settings can be accessed via <a href="javadoc/org/gradle/tooling/model/idea/IdeaProject.html#getJavaLanguageSettings--">`IdeaProject.getJavaLanguageSettings()`</a> and <a href="javadoc/org/gradle/tooling/model/idea/IdeaModule.html#getJavaLanguageSettings--">`IdeaModule.getJavaLanguageSettings()`</a>.

#### Generated Eclipse `.classpath` files specify the Java runtime used

The `.classpath` file generated via `eclipseClasspath` task provided by the Eclipse Plugin now points to an explicit Java runtime version rather than using the default JRE configured in the Eclipse IDE. The naming convention follows the Eclipse defaults and uses the `targetCompatibility` convention property from the `java` plugin to determine the default java runtime name.

To the name of the Java runtime to use can be configured via the `javaRuntimeName` property on the `EclipseJdt` model.

    eclipse {
        jdt {
            javaRuntimeName = "JavaSE-1.8"
        }
    }

#### Tooling API provides more Java language settings for Eclipse

The <a href="javadoc/org/gradle/tooling/model/eclipse/EclipseJavaSourceSettings.html">Java language settings</a> obtained for an `EclipseProject` from the Tooling API now include the target bytecode version and the build JDK for a Java project. These values can be used to better configure the Eclipse project created when when importing these projects into Eclipse. The target bytecode level is derived from the <a href="groovydoc/org/gradle/plugins/ide/eclipse/model/EclipseJdt.html#getTargetCompatibility">`eclipse.jdt.targetCompatibility`</a> property, while the JDK value indicates the JDK used by Gradle to build the project.

Look for improved support for importing Java projects in an upcoming release of <a href="http://projects.eclipse.org/projects/tools.buildship">Buildship</a>.

### Continuous build detects changes that occur during build execution

When introduced in Gradle 2.5, [continuous build](userguide/continuous_build.html) only observed changes that occurred after a build had completed. Continuous build will now trigger a rebuild when an input file is changed during build execution.

The rebuild is scheduled to start as soon as the currently executing build is complete. No attempt is made to cancel the currently executing build.

Following a build, if changes were detected, Gradle will report a list of file changes and begin execution of a new build.

### Support for controlling test execution order in TestNG

This version of Gradle adds support for TestNG preserveOrder and groupByInstances options to control test order execution. More information about these features can be found in the [userguide](userguide/java_plugin.html#test_execution_order).

New options can be enabled in the `useTestNG` block:

    test {
        useTestNG {
            preserveOrder true
            groupByInstances true
        }
    }

This feature was contributed by [<NAME>](https://github.com/kenji21).

### Test framework can be specified when bootstrapping a Java project

The [Build Init plugin](userguide/build_init_plugin.html) allows the bootstrapping of Gradle project via the built-in `init` task. It is now possible to use [Spock framework](https://code.google.com/p/spock/) or [TestNG](http://testng.org/doc/index.html) instead of JUnit for Java projects generated in this way. Specify the test framework as follows:

    gradle init --type java-library --test-framework spock

or

    gradle init --type java-library --test-framework testng

This feature was contributed by [<NAME>](https://github.com/calid).

### Published Ivy descriptor files include configured exclusions

The Ivy descriptor file generated by the ['ivy-publish'](userguide/publishing_ivy.html) plugin now includes dependency exclude information. Exclusions configured in your Gradle build script on project or external module dependencies will be included in the published _ivy.xml_ file.

This feature was contributed by [<NAME>](https://github.com/andrena-eike-kohnert).

### Configure Twirl source sets to use Java default imports

Previously, when compiling Twirl source sets, Gradle would assume that Scala default imports should be used.  A developer can now specify that Java default imports should be used when compiling a Twirl source set.

    model {
        components {
            play {
                twirlTemplates {
                    defaultImports = TwirlImports.JAVA
                }<commit_msg>Add some context in release notes<commit_after>The Gradle team is pleased to bring you Gradle 2.11. This release delivers significant improvements to the new [software model](userguide/software_model.html), together with improvements to IDE integration and continuous build.

The software model is the future of Gradle. The core software model is the basis of the native language and Play framework support in Gradle, and we are working intensively to bring full Java support. With this release, the new Java plugins support testing with JUnit and do a better job in compile avoidance. As well as developing our Java support, we continue to invest in the software model infrastructure, so support for developing any plugin with the new software model also got better.

Existing Java projects also benefit from Gradle 2.11. Improved IDE integration means that developing a Gradle project in IntelliJ IDEA or Eclipse is even better, with fewer tweaks to the IDE configuration required. These improvements encompass both the generated project files and the [Tooling API](userguide/embedding.html) used by IDEs to import Gradle projects.

By detecting changes that occur during build execution, [Continuous build](userguide/continuous_build.html) has become more dependable. We encourage users to try out this cool feature, which can really enhance the development experience with Gradle.

No Gradle release would be complete without contributions from the wonderful Gradle community. In Gradle 2.11, these contributions include:

- Controlling TestNG execution order with the [Java plugin](userguide/java_plugin.html).
- Specifying different test frameworks for a generated Java project using the [Build Init plugin](userguide/build_init_plugin.html).
- Specifying the Java default imports for a Twirl source set when developing with the [Play plugin](userguide/play_plugin.html).
- Publishing 'exclude' information to Ivy files using the [ivy-publish plugin](userguide/publishing_ivy.html).

The full list of contributions is below.

## New and noteworthy

Here are the new features introduced in this Gradle release.

### Better support for developing plugins with the software model

#### Plugins can use managed types for custom source set types

The `LanguageSourceSet` type can now be extended via `@Managed` subtypes, allowing for declaration of `@Managed` source sets without having to provide a default implementation.

Example:

    @Managed
    interface MarkdownSourceSet extends LanguageSourceSet {
        boolean isGenerateIndex()
        void setGenerateIndex(boolean generateIndex)
        boolean isSmartQuotes()
        void setSmartQuotes(boolean smartQuotes)
    }
    class RegisterMarkdown extends RuleSource {
        @LanguageType
        void registerMarkdown(LanguageTypeBuilder<MarkdownSourceSet> builder) {
            builder.setLanguageName("Markdown")
        }
    }
    apply plugin: 'language-base'
    apply plugin: RegisterMarkdown

    model {
        md(MarkdownSourceSet) {
            generateIndex = true
        }
    }

#### A `@ComponentBinaries` rule can create binaries for any `ComponentSpec` instance

The `@ComponentBinaries` annotation can now be used to create binaries for any component type, regardless of its enclosing container. It means that it can be used to define binaries for components in `components`, like it used to, but also for those defined in `testSuites`, or any custom `ComponentSpec` container.

### Improved building and testing Java libraries with the Java software model

#### Testing support

The Java software model now supports declaring a JUnit test suite as a software component, both as a standalone component or with a component under test. More information about declaring test suites can be found in the [userguide](userguide/java_software.html).

In addition, the changes in the software model infrastructure should make it easy to add support for new test frameworks.

#### Better compile avoidance

This version of Gradle further optimizes on avoiding recompiling consuming libraries after non-ABI breaking changes. Since 2.9, if a library declares an API, Gradle creates a "[stubbed API jar](userguide/java_software.html)". This enables avoiding recompiling any consuming library if the application binary interface (ABI) of the library doesn't change. This version of Gradle extends this functionality to libraries that don't declare their APIs, speeding up builds with incremental changes in most Java projects, small or large. In particular, a library `A` that depend on a library `B` will not need to be recompiled in the following cases:

- a private method is added to `B`
- a method body is changed in `B`
- order of methods is changed in `B`

This feature only works for local libraries, not external dependencies. More information about compile avoidance can be found in the [userguide](userguide/java_software.html).

### Enhanced support for developing Java projects in IntelliJ IDEA and Eclipse

Gradle supports IDE-centric development via both generated project files and direct IDE import using the Gradle Tooling API.

This release improves on this support for all Java projects built with Gradle, allowing the IDE view of a project to more closely model the Gradle configuration. Improvements to generated project files are available to try out immediately, while improvements to direct IDE import will require updates to IntelliJ IDEA and Buildship (Gradle support for Eclipse).

#### Generated IDEA files include correct module and project Java language level

The Gradle 'idea' plugin generates configuration files for a Gradle build to be opened and developed in IntelliJ IDEA. Previous versions of Gradle only considered the <a href="dsl/org.gradle.api.Project.html#org.gradle.api.Project:sourceCompatibility">`sourceCompatibility`</a> setting on the _root_ project to determine the 'IDEA Language Level': this setting on any subprojects was not considered.

This behavior has been improved, so that the generated IDEA project will have a 'Language Level' matching the highest `sourceCompatibility` value for all imported subprojects. For a multi-project Gradle build that contains a mix of `sourceCompatibility` values, the generated IDEA module for a sub-project will include an override for the appropriate 'Language Level' where it does not match that of the overall generated IDEA project.

If a Gradle build script uses the DSL to explicitly specify `idea.project.languageLevel`, the `sourceCompatibility` level is _not_ taken into account. In this case only the generated IDEA project will contain a value for 'Language Level', and no module-specific overrides will be generated.

The generated values for 'Language Level' are used when creating the `.ipr` and `.iml` files for a Gradle project, as well as to populate the Tooling API model that is used by IntelliJ IDEA on Gradle project import (see below).

#### Tooling API provides Java language settings for IntelliJ IDEA

The Tooling API exposes `IdeaProject` and the `IdeaModule` models that are used when importing a Gradle build into IntelliJ IDEA. These models not include information on the Java language settings that represent the Gradle configuration for an imported build, and should allow an imported Gradle project in the IDE to more closely match the build configuration.

Java language settings can be accessed via <a href="javadoc/org/gradle/tooling/model/idea/IdeaProject.html#getJavaLanguageSettings--">`IdeaProject.getJavaLanguageSettings()`</a> and <a href="javadoc/org/gradle/tooling/model/idea/IdeaModule.html#getJavaLanguageSettings--">`IdeaModule.getJavaLanguageSettings()`</a>.

#### Generated Eclipse `.classpath` files specify the Java runtime used

The `.classpath` file generated via `eclipseClasspath` task provided by the Eclipse Plugin now points to an explicit Java runtime version rather than using the default JRE configured in the Eclipse IDE. The naming convention follows the Eclipse defaults and uses the `targetCompatibility` convention property from the `java` plugin to determine the default java runtime name.

To the name of the Java runtime to use can be configured via the `javaRuntimeName` property on the `EclipseJdt` model.

    eclipse {
        jdt {
            javaRuntimeName = "JavaSE-1.8"
        }
    }

#### Tooling API provides more Java language settings for Eclipse

The <a href="javadoc/org/gradle/tooling/model/eclipse/EclipseJavaSourceSettings.html">Java language settings</a> obtained for an `EclipseProject` from the Tooling API now include the target bytecode version and the build JDK for a Java project. These values can be used to better configure the Eclipse project created when when importing these projects into Eclipse. The target bytecode level is derived from the <a href="groovydoc/org/gradle/plugins/ide/eclipse/model/EclipseJdt.html#getTargetCompatibility">`eclipse.jdt.targetCompatibility`</a> property, while the JDK value indicates the JDK used by Gradle to build the project.

Look for improved support for importing Java projects in an upcoming release of <a href="http://projects.eclipse.org/projects/tools.buildship">Buildship</a>.

### Continuous build detects changes that occur during build execution

When introduced in Gradle 2.5, [continuous build](userguide/continuous_build.html) only observed changes that occurred after a build had completed. Continuous build will now trigger a rebuild when an input file is changed during build execution.

The rebuild is scheduled to start as soon as the currently executing build is complete. No attempt is made to cancel the currently executing build.

Following a build, if changes were detected, Gradle will report a list of file changes and begin execution of a new build.

### Support for controlling test execution order in TestNG

Gradle's [Java plugin](userguide/java_plugin.html) provides a lot of options to configure test execution. This version of Gradle adds support for TestNG preserveOrder and groupByInstances options to control test order execution. More information about these features can be found in the [userguide](userguide/java_plugin.html#test_execution_order).

New options can be enabled in the `useTestNG` block:

    test {
        useTestNG {
            preserveOrder true
            groupByInstances true
        }
    }

This feature was contributed by [<NAME>](https://github.com/kenji21).

### Test framework can be specified when bootstrapping a Java project

The [Build Init plugin](userguide/build_init_plugin.html) allows the bootstrapping of Gradle project via the built-in `init` task. It is now possible to use [Spock framework](https://code.google.com/p/spock/) or [TestNG](http://testng.org/doc/index.html) instead of JUnit for Java projects generated in this way. Specify the test framework as follows:

    gradle init --type java-library --test-framework spock

or

    gradle init --type java-library --test-framework testng

This feature was contributed by [<NAME>](https://github.com/calid).

### Published Ivy descriptor files include configured exclusions

You can use to Gradle's [Ivy Publishing plugin](userguide/publishing_ivy.html) to publish build artifacts in the [Apache Ivy](http://ant.apache.org/ivy/) format. The Ivy descriptor file generated by the plugin now includes dependency exclude information. Exclusions configured in your Gradle build script on project or external module dependencies will be included in the published _ivy.xml_ file.

This feature was contributed by [<NAME>](https://github.com/andrena-eike-kohnert).

### Configure Twirl source sets to use Java default imports

Gradle's [Play plugin](userguide/play_plugin.html) provides support for configuring compilation of [Twirl](https://github.com/playframework/twirl) templates. Previously, when compiling Twirl source sets, Gradle would assume that Scala default imports should be used.  A developer can now specify that Java default imports should be used when compiling a Twirl source set.

    model {
        components {
            play {
                twirlTemplates {
                    defaultImports = TwirlImports.JAVA
                }
{'fraction_non_alphanumeric': 0.053226546531514624, 'fraction_numerical': 0.0014182622116547783, 'mean_word_length': 4.544403330249769, 'pattern_counts': {'":': 0, '<': 35, '<?xml version=': 0, '>': 35, 'https://': 9, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, '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': '5000885', 'n_tokens_mistral': 5856, 'n_tokens_neox': 5585, 'n_words': 3034}