Gradle 5.6 Update: Making Groovy Compilation Faster
These new features and enhancements are totally groovy, man.
Join the DZone community and get the full member experience.
Join For FreeIn this post, we will learn about the enhancements of about Gradle 5.6.
1. The Exit of Leaking Authentication Data
It was found that authentication data may leak while using the Gradle build tool to resolve dependencies against the custom authenticated repository. Officials are unaware of anyone having exploited the flaw, and thus, you should definitely upgrade the version since the features causing this issue are within the codebase and hard to disable.
2. Faster Groovy Compilation
This update has two latest features that help boost speed of Groovy compilation — Groovy compilation avoidance and incremental Groovy compilation.
Groovy compilation avoidance is the experimental feature that accelerates things by avoiding recompiling dependent projects if they don’t have anything that affects their output changed.
Incremental compilation means that if only small numbers of Groovy source files have been changed, only the affected source files are recompiled. Gradle doesn’t have to recompile every Groovy test source file. It will recompile only the changed classes and the classes affected by the changes.
3. Test Fixtures for Java Projects
Gradle 5.6 has a new Java test fixtures plugin that can be used along with Java or Java library plugin to create a traditional test fixtures source set. Gradle will run automated wiring so that test compilation depends on test fixtures. More significantly, the text fixtures plugin enables other projects to rely on the test fixtures of the project.
dependencies {
// this will add the test fixtures of "my-lib" on the compile classpath of the tests of _this_ project
testImplementation(testFixtures(project(":my-lib")))
}
4. Central Management of Plugin Versions With Settings Script
Gradle 5.6 makes central management of plugin versions simpler. Build scripts can us plugins through the plugins' {}
block without specifying a version by configuring all plugin versions in a setting script inside the latest pluginManagement.plugin {}
block.
pluginManagement {
plugins {
id 'org.my.plugin' version '1.1'
}
}
The block pluginManagement.plugins {}
doesn’t have the same constrained syntax as a block of build script plugins' {}
. These versions may be included from gradle.properties, or defined programmatically.
5. Better Performance for Big Projects on Windows
On the Windows platform, bigger projects encounter a significant performance decrease in Java compilation while shifting from the Java to the Java-library plugin. This usually happens due to a large number of class files on the classpath.
You can now command java-library plugin to use jars over class folders on the compile classpath. This can be done by setting the org.gradle.java.compile-classpath-packaging
system property to true.
6. Enhanced Handling of ZIP Archives on Classpaths
It is now possible to detect the most common zip extension instead of only supporting .jar with compile classpath and runtime classpath analysis.
Gradle 5.6 will check nested ZIP archives also instead of taking them as blobs. This will enhance the likelihood of build-cache hits for tasks that consider such nested zips as input. For instance, testing apps packaged as a fat jar.
ZIP analysis also neglects unpacking irrelevant entries, for instance, resource files on a compile classpath. This enhances performance for projects with a vast number of resource files.
7. Support for PMD Incremental Analysis
The PMD plugin allows using PMD’s incremental analysis cache that helps in enhancing performance when files have not changed between builds. You can add the following code to your PMD configuration to enable incremental analysis:
pmd {
incrementalAnalysis = true
}
8. Executable Jar Support With project.javaexec and JavaExec
Project.javaexec
and JavaExec
will now run an executable jar when the property of JavaExec.main
has not been set and the classpath changes to a single file.
In this scenario, Gradle will take the single jar in the classpath as an executable jar and will run it with java-jar
. If you want the proper execution, you need to set the main.class
attribute in the executable jar.
9. Fail the Build on Deprecation Warnings
The warning-mode
command line option can now use a new fail
value that will behave like all. It also fails the build in case any deprecation warning was reported during the execution.
10. Unavailable Files Are Handled Better
Generally, pipes and unreadable files or directories found in inputs and outputs of tasks are managed better than before.
11. Rich Console Output on Linux aarch64 Machines
With Gradle, it is now possible to detect that it is running in an interactive terminal on Linux aarch64 machines. It will generate rich console output on Linux aarch64 machines.
12. Promoted Features
Promoted features were incubating in earlier versions of Gradle but are now supported.
13. Known Issues
Known issues are problems discovered after the release. Those are directly related to changes introduced in Gradle 5.6. There are two known issues:
- Memory leak using tasks that apply Worker API and process isolation
- Duplicate entry generated .classpath file
There are enhancements in plugin authors and for tooling providers in Gradle 5.6 update. Java developers can read the entire Gradle 5.6 release notes here. You can provide your feedback for this post in the comments. If you have any question or doubt related to the changes in Gradle 5.6 version, feel free to drop those in the comments section as well.
References
http://docs.gradle.org/5.6-rc-1/release-notes.html
https://docs.gradle.org/5.6.2/release-notes.html
Further Reading
Opinions expressed by DZone contributors are their own.
Comments