Declarative Gradle EAP3 - April 2025 Update

Calendar
Sterling Greene
New Features
In April 2025, we announced the third Early Access Preview (EAP 3) of Declarative Gradle. Learn more about the release, try out the samples and share your feedback!

Table of Contents

Introduction #

This is an update on our experimental project called Declarative Gradle. We have just released a new Early Access Preview (EAP) that incrementally improves support for new datatypes in the Declarative Configuration Language (DCL) and makes it possible for simple real-world projects to try Declarative Gradle.

Declarative Gradle is part of our vision to deliver an elegant and extensible declarative build language that allows developers to describe any kind of software in a clear and understandable way. We think it will offer a fundamental advancement in the Gradle user experience and tooling capabilities for software developers.

Our first EAP release in July 2024 introduced a configuration model called Software Types, described a new configuration language, and demonstrated the potential for tooling improvements and better IDE support. Our second EAP release in November 2024 added support for the official Android Gradle Plugin and provided starter projects using DCL via gradle init.

This blog post provides an update on the project’s progress. We’ll cover new language features in the Declarative Gradle configuration language (DCL), improved support for testing, and lessons learned from adopting Declarative Gradle in one of our own projects. We’ll also explain how you can provide feedback and help shape what we build next.

Declarative Gradle is still in an experimental stage and is not ready for production use. We are providing a third early access preview to gather additional feedback from the community. We invite you to try out the samples and to let us know what you think.

If you would like to learn more, we’re holding a webinar on April 24, 2025.

Declarative Gradle - April 2025 Update

Support for testing #

For projects using Java or Kotlin, the prototype plugins have been updated to support simple testing with common test frameworks like JUnit – no complex build definitions required. These prototype plugins implement Software Types, which wrap existing plugins such as the Java Plugin and Kotlin Multiplatform (KMP) to make them usable in declarative definitions.

In a project file or settings defaults, you can declare dependencies on a testing framework—along with any other test-only dependencies—inside a testing {} block:

build.gradle.dcl

kotlinJvmLibrary {
    testing {
        dependencies {
            implementation("org.junit.jupiter:junit-jupiter:5.10.2")
            runtimeOnly("org.junit.platform:junit-platform-launcher")
        }
    }
}

Tests can be run from the IDE or command-line as usual.

New DCL Language Features #

We have continued to experiment with language features that allow broader support of definitions needed for real-world projects, such as lists and files.

List support #

The Declarative Configuration Language supports list properties. These properties are lists of strings, numbers, booleans, file types, or custom types.

List properties can be assigned using the = operator or added to using the += operator.

To assign or add to a list property, create a list using listOf(...). To add a single element to a list property, you must still use listOf(...):

build.gradle.dcl

javaApplication {
   jvmArguments = listOf("-Xmx512m")
}

List properties can have defaults configured in settings and overridden in project files. In project files, you can add to list properties that were initialized with defaults in settings:

settings.gradle.dcl

defaults {
   javaApplication {
      jvmArguments = listOf("-Xmx512m") 
   }
}

build.gradle.dcl

javaApplication {
   jvmArguments += listOf("-Dfoo=bar")
}

In this case, javaApplication.jvmArguments will contain both values:[-Xmx512m, -Dfoo=bar], combining the defaults with the project-specific additions.

List properties, like scalar properties, should only be assigned or added to once per block. Re-assignment of properties is considered non-declarative and not allowed in DCL files. If a property is modified multiple times, Gradle will produce an error when evaluating the project definition.

File support #

The Declarative Configuration Language supports file properties. Paths can be constructed for files or directories relative to the project directory or settings directory using layout.

File properties can be configured in the project’s build definition:

build.gradle.dcl

javaLibrary {
   checkstyle {
      // relative to the project 
      configFile = layout.projectDirectory.file("config/checkstyle.xml") 

      // relative to settings 
      configDirectory = layout.settingsDirectory.dir("config") 
   }
}

These properties can also be configured in settings.

Crucially, paths defined relative to the project directory are interpreted in the context of each individual project that uses the Software Type:

settings.gradle.dcl

defaults {
   javaLibrary {
      checkstyle {
         // relative to the project 
         configFile = layout.projectDirectory.file("config/checkstyle.xml") 

         // relative to settings
         configDirectory = layout.settingsDirectory.dir("config") 
      }
   }
}

This means the same relative path will resolve differently depending on which project applies the configuration. Note that layout does not provide access to the build directory.

IDE and Tooling Support #

Android Studio and IntelliJ IDEA have been updated to understand list and file properties. Syntax highlighting and auto-completion now support listOf(...) and layout. Here is a video of Android Studio:

VS Code has been updated to understand list and file properties. Syntax highlighting and auto-completion now support listOf(...) and layout:

We use a standalone Gradle Client to demonstrate future IDE capabilities. The Gradle Client has been updated to understand both list and file properties. Gradle now provides location information about where individual values are defined for list properties.

File properties are treated like other properties (String, Boolean, etc). Selecting a file property in the configured model will highlight the location in the script(s) where the value was set.

As shown in the video below, selecting a property in the configured model highlights the lines in the settings or project definitions that contributed to its final value.

Migrating our own project: What we learned #

As part of EAP3, we looked at migrating the Gradle Client project from Kotlin DSL build logic to DCL build files using software types. See the main branch of the repository for the example of build files using DCL–a settings.gradle.dcl in the root and a build.gradle.dcl file in each subproject.

We had to do more work than we expect will be necessary once Declarative Gradle fully supports composability and extensibility. Composability and extensibility allow different plugins to interact and extend the software definition. We recognize that migration is a major area for improvement, and we are actively exploring changes to make migrations easier in the future.

Despite these limitations, we think that Declarative Gradle is ready for users who are eager to experiment with Declarative Gradle in simple projects. For those interested, we’ve published a detailed case study describing how we migrated the Gradle Client, along with a migration guide for getting started.

Try Declarative Gradle Today #

If you want to try Declarative Gradle, you have two options. The migration guide and case study above demonstrate how to combine these two options in a build.

  1. If your project is simple enough to be covered by our prototype plugins, then you can just configure your project with them. The prototype Software Types support compiling and testing Java, Kotlin JVM, and Android applications but without publishing or third-party plugins.
  2. If your project uses third-party plugins or publishing, you will have to write your own Software Type(s) in build logic. When writing your own Software Type, you can leverage all the existing flexibility that Gradle plugins provide.

Declarative Gradle is still in an experimental stage, and APIs are likely to change or be removed. You can submit feedback to us.

Try Declarative Gradle

What’s Next? #

In upcoming releases, we plan to add support for additional data types (such as Maps) to the configuration language. We will also continue to improve IDE support and integration.

A key area of ongoing work is enabling composability and extensibility in Declarative Gradle. This has been a major area of focus for this EAP, but the work is not yet complete. Our goal is to allow plugins to contribute new configuration blocks to existing software types in a clean, scalable way.

Check out our roadmap for more detailed information.

Join us for the April 24 webinar! #

Join us for a live webinar on April 24 to learn how Declarative Gradle is redefining what it means to build software with Gradle. We’ll walk through the developer-first approach, show real-world examples, and share what’s coming next. Whether you’re just curious or already experimenting, this is a great chance to see what’s possible and ask questions directly.

Register for webinar

Learn More #

From the community:

Discuss

Related Posts