gradle / build-tool-roadmap Goto Github PK

• gradle/gradle#22797 (highly-voted issue)

The current plan is to upgrade to Groovy 4 in the next major release (8.0).

However an alternative path could be to stick with Groovy 3.x a bit longer. This is however tied to the evolution of Java Language version support planned for Groovy 3.
In short, Gradle would require Groovy 3 to still be compatible with Java 21 (September 2023 release)

Support running Gradle and building projects with JDK 19.

Related issues:

• gradle/gradle#20372

Gradle 8.0 introduces an interpreter for the declarative plugins {} block in .gradle.kts scripts that make overall script compilation time around 20% faster.

https://docs.gradle.org/8.0/release-notes.html#faster-kotlin-dsl-build-script-compilation

Provide further insight into variant aware dependency resolution results

Related issues:

• gradle/gradle#19763

Gradle 7.x uses Kotlin 1.4 to 1.6 depending on the exact version. However the Kotlin language level produced by script compilation remains at 1.4.

Gradle 8.0 should upgrade embedded Kotlin to 1.8 and most likely start targeting 1.8 language level.

Related issues:

• gradle/gradle#23214
• gradle/gradle#23749

Automate most of the approval checks as part of the plugin publication to the Plugin Portal to decrease the risk of human errors (and therefore increase security) and decrease wait time for plugin authors.

Gradle should offer the possibility of rerunning an individual task.

Related issues:

• gradle/gradle#9166

Previously, cleanup of the caches in Gradle user home used fixed retention periods (30 days or 7 days, depending on the cache). These retention periods can now be configured via the settings object in an init script in Gradle user home.

• gradle/gradle#7018 (highly-voted issue)

See https://docs.gradle.org/8.0/release-notes.html#cache-cleanup.

As of this writing there are 1,396 public types with 6,275 public methods available in Gradle’s public API to compile Java code against. Kotlin DSL and Groovy DSL each add some syntactic sugar on top of these. Some inconsistencies are bound to manifest over the years in such a large API.

One of the most significant inconsistencies is about our redundant configuration model. Historically, Gradle’s build model was configured using the JavaBeans model, i.e. properties defined via getters and setters. In 2017 we introduced the provider API as an alternative configuration model with a number of benefits, like lazy configuration, tracking build dependencies and lifecycle management on a fine-grained level.

The plan was to eventually convert the entirety of the Gradle API to the provider API, but it was never fully implemented. At present about 12% of public properties use provider API semantics. The rest is mostly exposed as JavaBean properties, but there is also a significant number of methods that conform to neither standard.

The inconsistency of our configuration model is the cause for some of the most reported problems, and the largest culprit for accidental complexity in Gradle builds. Full conversion would mean a lazy-only configuration model that would make some mistakes impossible to make that currently cause performance issues like cache misses, but can even result in incorrect builds. A lazy-only API also means we could track the origin of the value of a property, e.g. we can tell if a JavaCompile task is configured for Java 8 source compatibility because of a convention plugin, dictated by the JDK being used, or set from a build script. Some future features like coarse-grained execution, sandboxing and remote execution depend on a fully lazy API, or would be significantly simpler to implement with.

In Gradle 9.0 we are planning to migrate a large part of the remaining public API to use providers.

A demo of the upgrade experience can be tried here: https://github.com/gradle/provider-api-migration-testbed

The GitHub Dependency Graph is central to all aspects of GitHub supply chain security, including Dependency Review on PRs and Dependabot Security Alerts. The goal is to make it easy to enable the GitHub Dependency Graph for any project built with Gradle.

The Gradle dependency-graph support will consist of 2 parts:

1. The gradle/actions/dependency-submission action:

   • Provides a convenient mechanism to generate and submit a dependency gradle from a GitHub Actions workflow
   • Provides options to include/exclude particular projects and configurations from the dependency graph
   • Leverages the GitHub Dependency Graph Gradle Plugin

2. The GitHub Dependency Graph Gradle Plugin:

   • Collects all resolved dependencies for a Gradle execution, and export these in GitHub Dependency Graph format
   • Provides a custom task designed to resolve all possible dependencies for a build.
   • Could be used in other CI environments to generate a dependency-graph for submission to GitHub

Provide an easier way to declare dependency versions, especially in multiproject builds.

Delivered in Gradle 7.0

• gradle/gradle#23489
• gradle/gradle#23488

Roadmap document: https://docs.google.com/document/d/1uA3x13eOERYUVgMiPBnZytlTxzJ4BkVvU_yw0V2Z5bI/edit#

Improve TestLauncher interface in the Tooling API so that IDEs have a more efficient and more maintainable way to run tests through Gradle that is compatible with configuration cache.

Related issues:

• gradle/gradle#19759

File system watching is enabled by default but in very rare cases in esoteric environments it can cause unexpected issues when the underlying system events are unreliable.

Gradle will detect the reliability of file system events and automatically disable the file system watching optimization in case of issues.

Allow declaring a plugin with a version in a subproject in case the parent project also declared the same plugin in order to allow the use of dependency catalog plugin aliases in both a parent and subproject's plugins {}.

Improve the gradle-profiler tool so that it can be used to measure sync performance improvements (such as isolated projects) in a reproducible way.

In 8.1 we added an option to opt-in to Kotlin lazy property assignment, see #38.

We plan to enable it by default in 8.2 and stabilize it we switch to Kotlin 1.9.0 which has the last fixes - probably in 8.3.

Main reasons why it was not enabled by default before:

1. Kotlin assignment plugin with Kotlin 1.8.10 emits a warning that plugin is experimental. That might break some builds that use "all warnings are errors" flag for compilation
2. There are some important bugs with IDE integration in Kotlin 1.8.10, that were fixed in Kotlin 1.8.20: KT-56941, KT-56221

Relates to:
Concise and statically-typed Property<T> assignment

This allows the DSL provided by that plugin to fully replace the one provided by the plugin-publish plugin

Related issues:

• gradle/gradle#19982

With each major Gradle release, the range of supported Gradle versions by the tooling API is evaluated.
A possible outcome is to increase the minimum supported version.

Supports building software using Groovy 4.0

• gradle/gradle#20043

Kotlin DSL currently doesn't support an assignment for type Property as Groovy, but .set(T) have to be used. The goal is, that for types with inputs of type Property<T> we support =. This will ease the migration to Provider API for existing scripts and make the use of Provider API for new scripts more compelling.

Example
Types:

public interface Extension {
    Property<String> getDescription();
}
public interface OtherExtension {
    Property<String> getDescription();
}

Current DSL:

extension {
    description.set("value")
    description.set(otherExtension.description)
}

New DSL (.set(T) will still work):

extension {
    description = "value"
    description = otherExtension.description
}

In 8.1. we will introduce opt-in Kotlin lazy property assignment.

Related issue:

• gradle/gradle#9268

See RC release notes

Define a plan regarding the Provider API and evaluate how we could migrate all Gradle APIs to use it.

Explore ways to mitigate the pain related to this migration, for example through bytecode manipulation as in https://github.com/gradle/api-evolution-demo.

Configuration cache caches the configuration phase so that tasks start to execute much faster in subsequent builds. It also enables additional optimizations during execution like fine-grained parallelism enabled by default.

This issue is about making the configuration cache stable and production-ready.

More details are available on the Stable Configuration Cache project board.

Make it easier to add additional test groups like integration and functional tests.

To be released in Gradle 7.3.

Polish the remaining rough edges and un-incubate the version catalog feature and recommend it as the way to declare external dependencies.

The IntelliJ IDEA Plugin plugin will automatically mark all source directories used by a JVM Test Suite as test source directories within the IDE.

Simplify the Plugin Publish plugin by:

• removing the multiple ways of generating publication metadata and always relying on the Maven Publish plugin for it (plugin will be auto-applied)
• simplify the internals by using the Maven publications for everything (from artifacts to pom files)
• simplify the documentation
• address various issues reported in the past, in particular the insights of Daniel Lacasse

Provide a way for tools like Dependabot to reliably upgrade dependencies in order to avoid vulnerable ones.

Design spec is at https://docs.google.com/document/d/10OAehVIu3ehKvg60BMrMw5s3U7tTddeXIkyVw-KhFqU/.

See also dependabot/dependabot-core#1164.

Delivered in Gradle 7.0

Resolve the outstanding issues with Kotlin DSL, mostly about usability so it can be the default for new builds.

• Kotlin DSL can become the default in Android and other ecosystems

Use the file system watching infrastructure to make the continuous build feature more robust.

One of the practical outcomes of doing this is that continuous builds on macOS and Windows on Java 9 and later will react to file changes almost instantly, as opposed to the current delay that can be as long as 10 seconds between file change and new build being triggered.

Related issues:

• gradle/gradle#3427
• gradle/gradle#11834

Provide an easier way to aggregate code quality reports from multiple subprojects.

The goal for 2023 is to improve the project isolation prototype to a point where early adopter developers can enable project isolation for their daily development work and gain some significant improvement in average sync time.

Resolve the outstanding issues with Kotlin DSL, especially around script compilation performance, so that:

• Kotlin DSL can be fully recommended for all types of projects including large ones

With the 8.0 release, the team plans to clean up APIs:

• Remove deprecated ones
• Promote stable ones

Related issues:

• gradle/gradle#6305
• gradle/gradle#10066
• gradle]gradle#15023
• gradle/gradle#15496
• gradle/gradle#15503
• gradle/gradle#15875
• gradle/gradle#17151
• gradle/gradle#18852
• gradle/gradle#19158
• gradle/gradle#20097
• And more ...

Align it more with the features of the top level `dependencies block

Related issues:

• gradle/gradle#19192

Supports running on and building with Java 18

Related issues:

• gradle/gradle#19283

Ability for compilation to remain incremental even after a failed compilation.

Related issues:

• gradle/gradle#13601
• gradle/gradle#19602

Deliver experimental version of project isolation in order to decrease configuration time (in case it cannot be cached) and improve IDE sync time.

Provide the ability to compile Scala 3 code in the Scala plugin.

Improve usability and the look and feel of the documentation.

Provide a way for plugins to register a provider of Java Toolchain that will allow auto provisioning for any toolchain specification.

Related issues:

• gradle/gradle#19140

Configuration cache now enables more fine-grained parallelism than just enabling parallel execution. Starting in Gradle 8.0, tasks run in parallel from the first build when using the configuration cache.

https://docs.gradle.org/8.0/release-notes.html#more-parallelism-on-the-first-build

Toolchains for JVM projects feature uses AdoptOpenJDK by default. Changes are required to adjust to the move from AdoptOpenJDK to Eclipse Adoptium.

See also gradle/gradle#18027.

Add ability to declare that Gradle should not track the state of a task. This means that no optimizations are performed when running the task. For example, such a task will always be out of date and never come from the build cache.

It replaces Task.outputs.upToDateWhen { false }.

Produce an up-to-date and modern Kotlin DSL reference that will be based on Dokka.

See

• gradle/gradle#22953

Related issues:

• gradle/gradle#20536