The Gradle team is pleased to announce Gradle 3.0 M2.
This second release leading up to Gradle 3.0 builds on 3.0 M1 with several key improvements listed below. For more information, see the announcement blog post.
Check out some of the improvements we've made since Gradle 2.0. Lots of reasons to upgrade!
gradle --statusplugins DSL can resolve plugins without applying themeclipse-wtp plugineclipse-wtp plugineclipse plugin also applies eclipse-wtp for web projectsEclipseProject model.eclipse-wtp handling of external dependencies changedeclipse-wtp is automatically applied when the war or ear plugins are appliedGroovyObjectThis release is intended as a preview for new features we'll be releasing soon in Gradle 3.0. As such, it is not intended to be used in a production environment and features may change significantly before they are released in Gradle 3.0.
Here are the new features introduced in this Gradle release.
-release and -modulepath.The performance improvement gained by using the Daemon is staggering: our performance tests show that builds could be up to 75% faster, just by enabling the Gradle Daemon.
We have been working hard to make the Gradle Daemon aware of its health and impact on the system it's running on; and we believe that it is now robust enough to be enabled by default.
We encourage you to give the improved Daemon a try. If for some reason you encounter problems, you can disable the Daemon. Please submit feedback to us if you encounter instability so that we can make further improvements.
gradle --statusYou can now check the status of running Daemons. A sample:
$> gradle --status PID VERSION STATUS 28411 3.0 IDLE 34247 3.0 BUSY
Note that currently this does not list Gradle Daemons with version < 3.0. More details available in the User Guide.
Previously if a task's implementation class name changed, the class was deemed out-of-date even if its inputs and outputs matched the previous execution. However, if only the code of the task, or a dependent library changed, the task was still considered up-to-date. Since this version Gradle notices if the code of a task or its dependencies change between executions, and marks tasks as out-of-date when needed.
plugins DSL can resolve plugins without applying themThere are times when you want to resolve a plugin without actually applying it to the current project, e.g.
This is now possible using the following syntax
``` plugins { id 'my.special.plugin' version '1.0' apply false }
subprojects { if (someCondition) { apply plugin 'my.special.plugin' } }
```
eclipse-wtp pluginBefore Gradle 3.0, the eclipse-wtp plugin always defined external dependencies the WTP component descriptor. This caused several problems, listed at GRADLE-2123. To resolve this, the plugin now defines external dependencies in the Eclipse classpath and marks them as deployed/non-deployed accordingly. For each library a classpath entry similar to the one below is generated:
<classpathentry kind="lib" path=“/path/to/lib-1.0.0.jar" exported=“false">
<attributes>
<attribute name="org.eclipse.jst.component.dependency" value="WEB-INF/lib"/>
</attributes>
</classpath>If the project is not a Java project (and thus has no classpath), the dependencies are added to the component descriptor as before.
eclipse-wtp pluginThe eclipse-wtp plugin now fully leverages Gradle's dependency resolution engine. As a result, all dependency customisations like substitution rules and forced versions work in WTP projects.
eclipse plugin also applies eclipse-wtp for web projectsIf a project applies the war or ear plugins, then applying the eclipse plugin also applies eclipse-wtp. This improves the out-of-the box experience for Eclipse Buildship users.
EclipseProject model.The EclipseProject model was supplemented with a set of new features:
With these features Tooling API clients can provide a more complete IDE integration. Buildship will make use of them very soon.
Gradle 3.0 contains initial support for Java 9. This means that running Gradle on Java 9 and compiling, testing and running Java 9 applications is supported out of the box.
CAVEAT: Your mileage my vary. If you run into any problems please report those on the forums.
The OSGi plugin now uses the version 3.2.0 of the BND library.
Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. See the User guide section on the “Feature Lifecycle” for more information.
The following are the features that have been promoted in this Gradle release.
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 4.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.
The @OutputFiles and @OutputDirectories annotations support only properties with a Map type, where the values in the map can be resolved to individual files, while the keys represent unique identifiers for each file. Using either of the annotations with an Iterable<File> or FileCollection property is deprecated.
The following APIs have been deprecated:
TaskOutputs.files() method is now deprecated. Use either of the new TaskOutputs.namedFiles() methods instead.
Gradle itself now requires Java 7 or better to run, but compiling project sources and running tests with Java 6 remains supported. See Compiling and testing for Java 6 in the Userguide. There are also instructions on how to compile and test Groovy and Scala for Java 6.
Support for compiling and testing on Java 5 has been dropped.
The legacy Sonar plugin has been removed from the distribution. It is superceded by the official plugin from SonarQube (http://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Gradle).
The deprecated Ant-Based Scala Compiler has been removed from Gradle 3.0. The Zinc Scala Compiler is now used exclusively. The following properties have been removed from the ScalaCompile task:
daemonServerforkuseAntuseCompileDaemonThe support for declaring TestNG tests via javadoc annotations has been removed. The Test.testSrcDirs and the methods on TestNGOptions were removed, too, since they are not needed any more.
In previous versions, annotations on task properties like @InputFile and @OutputDirectory were only taken into account when they were declared on the task class itself, or one of its super-classes. Since Gradle 3.0 annotations declared on implemented interfaces are also taken into account.
eclipse-wtp handling of external dependencies changedFor Java projects, the eclipse-wtp plugin no longer adds external dependencies to the WTP component file, but to the classpath instead. Any customizations related to external dependencies that were made in the eclipse.wtp.component.file hooks now need to be done in the eclipse.classpath.file hooks instead.
eclipse-wtp is automatically applied when the war or ear plugins are appliedUser who are building war projects with Eclipse, but for any reason do not want to have WTP enabled can deactivate WTP like this:
eclipse.project { natures.removeAll { it.startsWith('org.eclipse.wst') } buildCommands.removeAll { it.name.startsWith('org.eclipse.wst') } }
AbstractTask methods setName() and setProject() are removed.plus(Iterable<FileCollection>) and #minus(Iterable<FileCollection>) methods have been removed from FileCollection.check, clean, build or assemble tasks is not allowed anymore when using the lifecycle plugin.beforeMerged or whenMerged is not allowed anymore.--no-color command-line option (use --console=plain instead).--parallel-threads command-line option (use --parallel + --max-workers instead).Zip.encoding (use Zip.metadataCharset instead).DistributionPlugin.addZipTask() and addTarTask().installApp task is no longer created by the application plugin (use installDist instead).Groovydoc.overview (use overviewText instead).LoggingManager.setLevel(). It is now not possible to change the log level during the execution of a task. If you were using this method to expose Ant logging messages, please use AntBuilder.setLifecycleLogLevel() instead.AntScalaCompiler in favor of ZincScalaCompiler.EclipseClasspath.noExportConfigurations property.ProjectDependency.declaredConfigurationName property.AbstractLibrary.declaredConfigurationName property.BuildExceptionReporter.BuildLogger.BuildResultLogger.TaskExecutionLogger.ConflictResolution.Module.DeleteAction.EclipseDomainModel.AntGroovydoc.AntScalaDoc.BinaryType.LanguageType.ConventionValue.org.gradle.platform.base.test.TestSuiteBinarySpec replaced by org.gradle.testing.base.TestSuiteBinarySpecorg.gradle.platform.base.test.TestSuiteContainer replaced by org.gradle.testing.base.TestSuiteContainerorg.gradle.platform.base.test.TestSuiteSpec replaced by org.gradle.testing.base.TestSuiteSpecSpecs.and(), Specs.or() and Specs.not()StartParameter.getParallelThreadCount() and StartParameter.setParallelThreadCount()PrefixHeaderFileGenerateTask.getHeaders()org.gradle.tooling.model.Task.getProject()Logging.ANT_IVY_2_SLF4J_LEVEL_MAPPERurlRoot, distributionName, distributionVersion and distributionClassifierhas(), get() and set() dynamic methods exposed by ExtraPropertiesDynamicObjectAdapterGroovyObjectThe EclipseProjectDependency and EclipseExternalDependency models now contain ClasspathAttributes. By default the JavaDoc location attribute and WTP deployment attributes are populated.
Any customizations done via eclipse.classpath.file.beforeMerged and eclipse.classpath.file.whenMerged are also reflected in these tooling models.
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.
GRADLE-3491 - Android Library projects do not pick up changes