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 --status
plugins
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 appliedGroovyObject
This 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 --status
You 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:
daemonServer
fork
useAnt
useCompileDaemon
The 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.TestSuiteBinarySpec
org.gradle.platform.base.test.TestSuiteContainer
replaced by org.gradle.testing.base.TestSuiteContainer
org.gradle.platform.base.test.TestSuiteSpec
replaced by org.gradle.testing.base.TestSuiteSpec
Specs.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_MAPPER
urlRoot
, distributionName
, distributionVersion
and distributionClassifier
has()
, get()
and set()
dynamic methods exposed by ExtraPropertiesDynamicObjectAdapter
GroovyObject
The EclipseProjectDependency
and EclipseExternalDependency
models now contain ClasspathAttribute
s. 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