The Gradle team is pleased to bring you Gradle 2.11. This release delivers significant improvements to the new software model, 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 used by IDEs to import Gradle projects.
By detecting changes that occur during build execution, Continuous build 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:
The full list of contributions is below.
getPatternSetFactory method added to SourceTaskFileVisitDetailsHere are the new features introduced in this Gradle release.
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
}
}@ComponentBinaries rule can create binaries for any ComponentSpec instanceThe @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.
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.
In addition, the changes in the software model infrastructure should make it easy to add support for new test frameworks.
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". 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:
BBBThis feature only works for local libraries, not external dependencies. More information about compile avoidance can be found in the userguide.
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).
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 sourceCompatibility 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).
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 IdeaProject.getJavaLanguageSettings() and IdeaModule.getJavaLanguageSettings().
.classpath files specify the Java runtime usedThe .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"
}
}The Java language settings 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 eclipse.jdt.targetCompatibility 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 Buildship.
When introduced in Gradle 2.5, continuous build 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.
Gradle's Java plugin 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.
New options can be enabled in the useTestNG block:
test {
useTestNG {
preserveOrder true
groupByInstances true
}
}This feature was contributed by Richard Bergoin.
The Build Init plugin allows the bootstrapping of Gradle project via the built-in init task. It is now possible to use Spock framework or TestNG instead of JUnit for Java projects generated in this way. Specify the test framework as follows:
gradle init --type java-library --test-framework spockor
gradle init --type java-library --test-framework testngThis feature was contributed by Dylan Cali.
You can use to Gradle's Ivy Publishing plugin to publish build artifacts in the Apache 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 Eike Kohnert.
Gradle's Play plugin provides support for configuring compilation of 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
}
}
}
}By convention, the CUnit and Google Test plugins will create and configure a test suite for each component automatically. It is now possible to opt-out of this conventional behaviour by applying the a base 'test-suite' plugin, with the component under test being specified explicitly using the testing $.components.someComponent reference syntax.
The cunit plugin is now built on top of the cunit-test-suite plugin and applies the convention of creating a test suite for each native component automatically. Similarly, the google-test plugin is built on top of the google-test-test-suite plugin. This change allows finer-grained control over the creation of native test suites, addressing issues where Gradle proactively creates test suites for components it should not.
With this change, the native software model and Java software model use the same pattern for defining test suites.
As a result of some user feedback, some changes have been made to the outputs resulting from the stage and dist task in the incubating Play framework plugins.
lib directoryWhen copying dependencies into the Play distribution's lib directory, we now rename all jar files to include group or project path information. This fixes an issue where a Play component depends on multiple projects having the same name.
The Gradle Play plugin now adds a Tar task to build standalone Play distributions (createPlayBinaryTarDist). A tar and zip distribution will be created when executing dist.
The name of the Zip task to create standalone Play distributions is now createPlayBinaryZipDist.
If you would like to have a different archive name (by default, playBinary.zip or playBinary.tar), you must configure the baseName property for the Zip or Tar tasks. When determining the final archive name, Gradle will concatenate the baseName and extension.
For tar files, Gradle will automatically switch to using .tgz or .tbz2 when the compression property is changed.
Previously, it was possible to directly set the archiveName for the generated Zip. This property is now ignored. The version, appendix and classifier properties are still ignored when calculating the archive name.
Features that have become superseded or irrelevant due to the natural evolution of Gradle become deprecated, and scheduled to be removed in the next major Gradle version (Gradle 3.0). See the User guide section on the “Feature Lifecycle” for more information.
The following are the newly deprecated items in this Gradle release. If you have concerns about a deprecation, please raise it via the Gradle Forums.
Specs.or() has been deprecated and will be removed in Gradle 3.0. You should use Specs.union() instead.Specs.and() has been deprecated and will be removed in Gradle 3.0. You should use Specs.intersect() instead.Specs.not() has been deprecated and will be removed in Gradle 3.0. You should use Specs.negate() instead.Dependency exclusions are now added to the published ivy.xml when using the 'ivy-publish' plugin. This may result in dependencies being resolved by consuming projects of newly published modules to change. If consuming projects depend on the excluded dependencies you may have to explicitly add these dependencies to the consuming project.
Gradle uses the Apache HttpComponents HttpClient library internally for features like dependency resolution and publication. This library has been updated from version 4.2.2 to 4.4.1. As part of this upgrade, certain system properties are no longer taken into account when creating clients used for resolving and publishing dependencies from HTTP repositories. Specifically, the 'http.keepAlive' and 'http.maxConnections' system properties are now ignored.
Additionally, as part of this upgrade, system properties are now taken into consideration by the client used for resolving plugins from the Gradle Plugin Portal. This means that configured proxy or SSL settings will be used when accessing the Plugin Portal.
For more information regarding changes introduced in HttpClient 4.4.1 please see the HttpClient release notes.
Adding the 'scala' plugin to your build will no longer create a 'scalaConsole' task to launch a Scala REPL from the Gradle build. This capability has been removed due to lack of documentation and support for running with the Gradle Daemon. If you wish to continue to have such a task as part of your build, you can explicitly configure a JavaExec task to do so.
When a continuous build is running, Gradle will begin monitoring changes to a task inputs just before that task executes. If a task modifies its own inputs, or the inputs of a task that it depends on, this can lead to a build cycle where each build triggers another build.
This problem can be diagnosed by inspecting the list of files reported when the next build is triggered. Changing the logging level to --info can make it easier to identify which input files cause which tasks to become out-of-date.
getPatternSetFactory method added to SourceTaskAn injected getPatternSetFactory() method has been added to the org.gradle.api.tasks.SourceTask class. This is a possible breaking change for unit tests of tasks that extend the SourceTask class.
The value for PmdExtension is now ["java-basic"] instead of ["basic"]. This matches the value for the default version of PMD used by Gradle (5.2.3). Gradle will still convert 'java-basic' to 'basic' when a pre-5.0 version of PMD is used, so this change will only effect builds that use PMD 4.x and add additional rulesets to the list provided by the PmdExtension.
FileVisitDetailsPrior to Gradle 2.10, most implementations would delegate calls to FileVisitDetails.getLastModified() and FileVisitDetails.getSize() to the actual visited file. Gradle 2.10 introduced an optimisation where these values were read eagerly for some implementations of FileVisitDetails on some Java versions.
In Gradle 2.11, this behaviour is consistent across all Java versions and operating systems. The values for lastModified and size are determined eagerly when visiting a File tree. This provides a more consistent, reliable API and permits Gradle to make optimizations when reading these values.
Gradle 2.9 exposes methods through the GradleRunner API for providing a target Gradle distribution used to executed the build. There are known, functional limitations of TestKit for particular Gradle versions. If a certain feature is not supported, TestKit throws an exception. Please check the user guide for an overview of known TestKit limitations.
CollectionBuilder interface removed.ManagedSet interface removed.JvmBinaryTasks removed, replaced with JarBinarySpec.TasksCollection, for consistency with the native binaries.JvmBinarySpec.getTasks() removed, replaced with JarBinarySpec.getTasks().assemble task now builds only those binaries for components defined in components. It does not build binaries for test suites defined in testSuites.LanguageBasePlugin has been split into two separate plugins: LanguageBasePlugin and BinaryBasePlugin.LanguageBasePlugin no longer applies the full component model.@LanguageType annotation implicitly applies only the LanguageBasePlugin.@BinaryType annotation implicitly applies only the BinaryBasePlugin.getcCompiler() are now allowed and addressable via cCompiler.getCFlags() are now addressable via cFlags instead of the erroneous CFlags.getURL() are now addressable via URL instead of the erroneous uRL.runtimeClassesDir property has been removed. Inputs should be configured via the usual task.inputs mechanism.destinationDir and archiveName have been consolidated into the single outputFile property.apiClassesDir property was no longer necessary and has been removed.We would like to thank the following community members for making contributions to this release of Gradle.
We love getting contributions from the Gradle community. For information on contributing, please see gradle.org/contribute.
Known issues are problems that were discovered post release that are directly related to changes made in this release.