Gradle 4.0-rc-1 is now available for testing


(Benjamin Muschko) #1

The Gradle team is pleased to announce Gradle 4.0-rc-1.

We are excited to share some great new features and improvements with you in this release:

First and foremost, Gradle’s Build Cache is now production-ready for Java and Groovy compilation and Java test tasks! This is further improved by overlapping outputs detection, configurable classpath normalization that avoids unnecessary task execution, and more listed in the full release notes. The cacheability of other tasks, including other languages, will be completed in future releases.

Now on to user experience: this release has a number of enhancements in logging and terminal display. Log output is now grouped by project and task when attached to a terminal — output from tasks run in parallel will no longer be interleaved. However, logging behaves the same as previous Gradle versions in non-interactive environments, and with --console=plain, to allow automated tools like CI systems to parse the logs they expect.


The console output now shows more detail about what exactly is in-progress, and parallel work in-progress is now displayed by default. You can learn more about logging and console output in the user guide.


Speaking of parallel work-in-progress, artifacts and metadata from remote repositories are now downloaded in parallel! Gradle also avoids downloading the same dependency twice even if parallel tasks request the same one simultaneously.

Gradle Script Kotlin v0.9.0 (included in this release) brings very welcome improvements: auto-detection of Kotlin build scripts, default imports for the whole Gradle API, improved samples and docs with an API reference, better IntelliJ experience and more!

Finally, this release introduces a public type that represents lazily-evaluated properties (aka ConventionMapping). This is one of the most-requested features by plugin authors. You can learn more about PropertyStates here. A good example of their usage can be found in the gradle-site-plugin.

We hope you will build happiness with Gradle 4.0, and we look forward to your feedback via Twitter or on GitHub.

Upgrade Instructions

Switch your build to use Gradle 4.0 RC1 quickly by updating your wrapper properties:

./gradlew wrapper --gradle-version=4.0-rc-1

Standalone downloads are available at https://gradle.org/release-candidate.

Reporting Problems

If you find a problem with Gradle 4.0 RC1, please file a bug on GitHub Issues adhering to our issue guidelines. If you’re not sure you’re encountering a bug, please use the forum.


(Benjamin Muschko) #2

(Ben Manes) #3

The behavior of JavaDoc generation changes in this release, causing it to break when compared to 3.5.

Task :jcache:javadoc
javadoc: error - Illegal package name: “http://static.javadoc.io/javax.cache/cache-api/1.0.0/’ '/Users/ben/projects/caffeine/jcache/build/jcache-docs”

It is configured as,

javadoc.dependsOn(unzipJCacheJavaDoc)
javadoc.options.addStringOption(‘Xdoclint:none’, ‘-quiet’)
javadoc.options.linksOffline(
http://static.javadoc.io/javax.cache/cache-api/${versions.jcache}/”,
"${buildDir}/jcache-docs",
)

That should make it generate the links without performing an http query for the directory listing, which fails as not permitted. Since that is unnecessary the generated JavaDoc is valid, except this workaround now fails the build.


(high-stakes) #4

Hi,

What is the advantage of using PropertyState over simple Closures? Looks like it needs the same amount of work as closures (2 separate setters, etc) and ConventionMapping is still simpler to use.


(Benjamin Muschko) #5

@Benjamin_Manes Thanks for reporting the issue. It is very likely the same as https://github.com/gradle/gradle/issues/2235. We’ll fix that for 4.0-RC2.


(Benjamin Muschko) #6

@high-stakes There are various reasons for introducing the new concept:

  1. Convention mapping is an internal API and will not be public. It can change with any release and break external plugins without warning.
  2. Convention mapping is not documented and has it’s quirks. It’s easy to get wrong and auto-generates getter methods which have to be used in a task action.
  3. The new Provider concept will likely make it into other portions and APIs of Gradle and therefore become a more general concept.

(Benjamin Muschko) #7