days
-4
-6
hours
-1
-2
minutes
-3
-8
seconds
-1
-2
search
JAX Developers Puzzle deadline approaching: Play for a chance to win a complimentary JAX London 2018 ticket!
Construction site safety — not enabled by default

Gradle 3.5 focuses all of its attention on build cache

Gabriela Motroc
Gradle 3.5

Construction warning sign image via Shutterstock

The star of the new Gradle release is indubitably the new build cache. Although the team has worked hard to make sure that many built-in tasks are cacheable, it is not recommended to use this feature in production without fully understanding its current limitations. Therefore, it is not enabled by default.

Gradle is back. It’s been one month since 3.4 was released [which brought improvements to the Java ecosystem], so it’s time for another release to steal the spotlight.  The star of Gradle 3.5 is undoubtedly the new build cache; according to the blog post announcing the release, “beyond incremental builds, Gradle can save time by reusing outputs from previous executions of a task, resolving them locally or remotely.”

Even though the team has tried to make sure that many built-in tasks are cacheable and safe to try, this feature should not be used in production if its current limitations are not fully understood. As a result, it is not enabled by default — but the user experience, documentation, and debuggability are being improved “so that everyone can enable the Build Cache eventually.”

What’s new in Gradle 3.5?

The team confessed that they lamented that sometimes Gradle console output did not show all work-in-progress during a build (especially with --parallel), so they’ve developed a brand new console output.

Gradle Script Kotlin v0.8.0 (included in the distribution) brings a more consistent DSL, convenient and type-safe access to contributed project extensions and conventions, as well as much better error reporting, bug fixes and the latest and greatest Kotlin release.

Gradle now allows users to adjust how plugins are resolved by providing plugin resolution rules. Users can specify a default version for a plugin to make sure they don’t have to repeat it in every project or they can tell Gradle what implementation artifact it should look for in case the plugin is not published with plugin markers.

pluginManagement {
    repositories {
        maven { url = 'someUrl'}
    }
    resolutionStrategy {
        eachPlugin {
            if (requested.id.namespace = 'my.plugins') {
                useVersion('1.3')
            }
        }
    }
}

The pluginManagement block supersedes the existing pluginRepositories block. Users have full access to the Settings DSL inside that block. Furthermore, plugin management can now be configured from an init script by using the settingsEvaluated {} hook.

Extensions can now be registered in ExtensionContainers with an explicit public type, according to the blog post. This enables plugin authors to hide their implementation type from build scripts and allow ExtensionContainers to expose a schema of all the registered extensions.

Build cache overview

The goal of the Gradle build cache is to save time by reusing outputs produced by other builds; it stores (locally or remotely) build outputs and allows builds to fetch these outputs from the cache when it is determined that inputs have not changed, thus avoiding the expensive work of regenerating them.

According to the blog post, task output caching leverages the same intelligence as up-to-date checks that Gradle uses to avoid work when a previous local build has already produced a set of task outputs. However, the difference is that “instead of being limited to the previous build in the same workspace, task output caching allows Gradle to reuse task outputs from any earlier build in any location on the local machine. When using a shared build cache for task output caching this even works across developer machines and build agents.”

Other features will use the build cache in the future.

The build cache can be enabled in two ways:

  • Run with --build-cache on the command-line. Gradle will use the build cache for this build only.
  • Put org.gradle.caching=true in your gradle.properties. Gradle will try to reuse outputs from previous builds for all builds, unless explicitly disabled with --no-build-cache.

When the build cache is enabled, it stores build outputs in the Gradle user home.

For a complete list of changes, check out the release notes.

Author
Gabriela Motroc
Gabriela Motroc is editor of JAXenter.com and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Leave a Reply

Be the First to Comment!

avatar
400
  Subscribe  
Notify of