1. Overview

Groovy is the default language for writing Gradle scripts. However, since Gradle version 5.0, we can write these scripts in Kotlin, too.

In this tutorial, we’ll look at how we can write Gradle scripts in Kotlin. We will also look at some advantages and disadvantages of using Kotlin DSL scripts.

2. How to Create a Kotlin DSL Script

To write Kotlin DSL scripts, we need to use Gradle version 5.0 or later. To activate the Kotlin DSL and get the best IDE support, we need to use the following extensions:

  • .gradle.kts instead of .gradle for our build scripts
  • .settings.gradle.kts instead of .settings.gradle for all settings scripts
  • .init.gradle.kts instead of .init.gradle for initialization scripts

3. How to Write a Basic Gradle Script for a Java Library

In this section, we’ll go through the different building blocks of a Gradle script written in Kotlin DSL script. We will also look at the differences compared to when writing the same script in Groovy DSL.

3.1. Applying Plugins

We can apply the java-library plugin, which is a core plugin:

plugins {

Please note that we don’t need to specify the id function – unlike in Groovy DSL – for core plugins.

We can apply a community plugin by specifying the fully qualified plugin id and version:

plugins {
    id("org.flywaydb.flyway") version "8.0.2"

3.2. Declaring Dependencies

We can declare different types of dependencies using type-safe accessors:

dependencies {

The important thing to note here is that the Kotlin DSL makes all four accessors available in the body of the Gradle script immediately after the plugins {} block. This means that when composing this script, we will have type-safe auto-completion in supported IDEs. This results in a fast and superior scripting experience.

3.3. Declaring Repositories

We can declare both built-in and custom repositories using type-safe accessors:

repositories {
    maven {
        url = uri("https://maven.springframework.org/release")

While resolving a dependency, Gradle will first check the maven-central repository followed by the springframework repository.

3.4. Configuring Source Sets

Let’s say we want to define a separate source set for our integration tests. The project layout is:

  ├── src 
  │    └── main 
  │    |    ├── java 
  │    |    │    ├── DefaultSorter.java
  │    |    │    ├── InMemoryRepository.java
  │    |    │    ├── Reporter.java
  │    |    │    ├── Repository.java
  │    |    │    ├── Sorter.java
  │    ├── test 
  │    |    ├── java 
  │    |    │    └── DefaultSorterTest.java
  │    |    │    └── InMemoryRepositoryTest.java
  │    |    │    └── ReporterTest.java
  │    └── integrationTest 
  │         └── java 
  │              └── ReporterIntegrationTest.java
  └── build.gradle

We can define the integrationTest source set as:

sourceSets {
    create("integrationTest") {
        compileClasspath += sourceSets.main.get().output
        runtimeClasspath += sourceSets.main.get().output

With this setup, we create a Gradle task called compileIntegrationTestJava. Using this task, we can compile the source files inside the src/integrationTest/java directory.

3.5. Defining a Custom Gradle Task

We need a task to run the integration tests. We can create it using Kotlin DSL:

val integrationTest = task<Test>("integrationTest") {
    description = "Task to run integration tests"
    group = "verification"

    testClassesDirs = sourceSets["integrationTest"].output.classesDirs
    classpath = sourceSets["integrationTest"].runtimeClasspath

Here, we created a custom task using the Kotlin extension function task that is attached to the Project object. This is different from the Groovy syntax because there we would use the TaskContainer object to create a custom task. This is possible in Kotlin DSL too, but it’s more verbose.

4. Running Command-Line Command With Kotlin DSL

We can use Kotlin DSL to run command-line commands, enhancing our build workflow. In this section, we’ll explore a few scenarios to learn this in detail.

4.1. Creating Command-Line Task

First, let’s create the helloUserCmd task in the build.gradle.kts build script, and look at it in its entirety:

tasks.register("helloUserCmd") {
    val user: String? = System.getenv("USER")
    project.exec {
        commandLine("echo", "Hello,", "$user!")

Let’s break this down to understand the building blocks of the helloUserCmd task. Firstly, we used the tasks.register() function to define the task. Further, we used the project.exec function to configure the execution of an external command with the help of the commandLine() method. Lastly, it’s important to note that we used the System.getenv() method to retrieve the username from the environment.

Next, let’s run the helloUserCmd task and see it in action:

$ ./gradlew helloUserCmd
7:23:17 AM: Executing 'helloUserCmd'...
> Task :helloUserCmd
Hello, tavasthi!
1 actionable task: 1 executed
7:23:19 AM: Execution finished 'helloUserCmd'.

Great! It worked as expected.

4.2. Capturing Command Output in a Variable

We might sometimes want to capture the command output in a variable for later reuse. Let’s learn how to solve this use case.

Let’s begin by using the logic from the helloUserCmd task to define the helloUserInVarCmd task:

tasks.register("helloUserInVarCmd") {
    val user: String? = System.getenv("USER")
    val outputStream = ByteArrayOutputStream()
    project.exec {
        standardOutput = outputStream
        commandLine("echo", "Hello,", "$user!")
    val output = outputStream.toString().trim()
    println("Command output: $output")

We can notice that the only additional logic in this task is the redirection of standard output to an instance of ByteArrayOutputStream class. Furthermore, we captured the value of outputStream in the output variable to use later in a println() statement.

Now, let’s run the helloUserInVarCmd task and verify its behavior:

$ ./gradlew helloUserInVarCmd
7:25:15 AM: Executing 'helloUserInVarCmd'...
> Task :helloUserInVarCmd
Command output: Hello, tavasthi!
1 actionable task: 1 executed
7:25:16 AM: Execution finished 'helloUserInVarCmd'.

Perfect! We can see that the println() statement containing the command output worked as expected.

4.3. Capturing Command Output in a File

Let’s solve a similar use case where we want to capture the output in a file. For this purpose, let’s imagine that we want to capture the filenames from the /tmp directory in the output.txt file. So, let’s go ahead and write the tmpFilesCmd task in the build.gradle.kts build script:

tasks.register("tmpFilesCmd") {
    val outputFile = File("/tmp/output.txt")
    val outputStream: OutputStream = FileOutputStream(outputFile)
    project.exec {
        standardOutput = outputStream
        workingDir = project.file("/tmp")
        commandLine("ls", workingDir)

It’s interesting to note that we’ve defined an instance of the FileOutputStream to redirect the standard output to the underlying file. Additionally, we used the project.file() method to use /tmp as an argument for the ls command.

Now, let’s run the tmpFileCmd task and validate the contents of the output.txt file:

$ ./gradlew tmpFilesCmd
7:26:10 AM: Executing 'tmpFilesCmd'...
> Task :tmpFilesCmd
1 actionable task: 1 executed
7:26:11 AM: Execution finished 'tmpFilesCmd'.

$ head -2 /tmp/output.txt 

Fantastic! With this, we’ve got a good understanding of capturing command output.

4.4. Handling Failure

When we execute an external command using the project.exec function, Gradle fails execution of the task if the command returns with a non-zero exit status. Although it might be the desired behavior in some use cases, we might want to handle failures in some cases.

To understand this, let’s write the alwaysFailCmd task that executes the ls command for a non-existent path:

tasks.register("alwaysFailCmd") {
    val result = project.exec {
        commandLine("ls", "invalid_path")
        isIgnoreExitValue = true
    if (result.exitValue == 0) {
        println("Command executed successfully.")
    } else {
        println("Command execution failed.")
    println("Command status: $result")

Now, let’s understand the nitty gritty of the logic. The foremost thing to note is that we’ve set the isIgnoreExitValue to true so that Gradle doesn’t consider task execution a failure when the ls command fails. Further, we’ve captured the execution result of the project.exec() function in the result variable to get the exit status of the command. Lastly, we check the exitValue attribute of the result variable to add the failure handler logic, which in this case, is a simple println() statement.

Now, let’s execute the alwaysFailCmd task:

$ ./gradlew alwaysFailCmd
7:27:08 AM: Executing 'alwaysFailCmd'...
> Task :alwaysFailCmd
Command execution failed.
Command status: {exitValue=1, failure=null}
1 actionable task: 1 executed
ls: invalid_path: No such file or directory
7:27:09 AM: Execution finished 'alwaysFailCmd'.

As expected, even though the ls command failed with an exitValue=1, Gradle executed the task successfully.

5. IDE Support

Since Kotlin is a statically typed language, unlike Groovy, IDEs can provide several useful features like auto-completion, source code navigation, refactoring support, and error highlighting for Gradle scripts. This means we can enjoy a similar coding experience as we normally do when writing application code in Kotlin or Java. Currently, IntelliJ IDEA and Android Studio provide the best support for Kotlin DSLs.

6. Limitations

The Kotlin DSL has some limitations compared to Groovy especially when comparing the speed of script compilation. There are some other uncommon limitations mentioned on the Gradle official website.

7. Conclusion

In this article, we learned how to compose Gradle scripts using the Kotlin DSL. We also looked at some differences between Gradle scripts written in Groovy and those written in Kotlin DSL. Furthermore, we learned how to use Kotlin DSL for running command-line commands.

As usual, all code examples are available over on GitHub.

Comments are closed on this article!