Gradle 5.6 has been released in August 2019 as the final release for Gradle 5.x and brings a lot of features as a preparation for Gradle 6.0.

Test fixtures

When you are writing a library module, you structure the code in source sets:

• Production code is placed to src/main/kotlin and shared with modules that depend on it.
• Test code is placed to src/test/kotlin and is not shared anywhere.

The missing piece here is Test Fixtures code.

• Test Fixtures code is placed to src/testFixtures/kotlin and shared with any test source set (src/test/kotlin) of modules that depend on it.

What is it good for? You can share common pieces for writing tests, such as Test Assertions or fake test data to avoid test code duplication as your consuming modules don't need to create them on their own again and again.

First, I was super excited about this! But when I tested it on real Android project, the feature appeared not compatible with Android Gradle Plugin at all (it works for plain Java projects only).

Anyway, Android Tooling team has already start working on this (see Issue 139762443 and Issue 139438142), so 🤞.

Central management of plugin versions with settings script (docs)

If you are not using buildSrc included build to organize the build logic you might end up specifying version of Gradle plugins in plugins {} block for every module of your project. This approach has few constrains as you are not able to read the version i.e. from gradle.properties.

To address this Gradle 5.6 introduces a new way of specifying plugin version in root settings.gradle.kts file (also with gradle.properties support):

    val helloPluginVersion: String by settings // reads value from `gradle.properties`
    pluginManagement {
        plugins {
            id("org.gradle.sample.hello") version "${helloPluginVersion}"
        }
    }

Then in the module's build.gradle.kts file the plugin declaration don't need to specify the version anymore:

    plugins {
        id("org.gradle.sample.hello")
    }

Fail the build on deprecation warnings (docs)

If you want to be 100% build warning free, you can configure Gradle to fail the build for any Gradle deprecation warning. Just add this to gradle.properties:

    org.gradle.warning.mode=fail       # other options are all/summary/none

Correct handling of file name case on case-insensitive file systems (docs)

Fixes issues with Copy and similar Gradle tasks on case-insensitive file systems like NTFS (Windows) or APFS (macOS).

Conclusion

That's it for Gradle 5.x releases. Please stay tuned for the Gradle 6.0 blog post. 😉