The syntax for configuring tasks is where the Groovy and Kotlin DSLs start to differ significantly.

In Kotlin, Tasks are namespaced into the tasks container build.gradle jar { archiveName = "foo.jar" } build.gradle.kts tasks.jar { archiveName = "foo.jar" }

Note that in Kotlin the tasks.jar {} notation leverage the configuration avoidance API and defer the configuration of the jar task.

If the type-safe task accessor tasks.jar isn’t available, see the Configuring plugins section above, you can fallback to using the tasks container API. The Kotlin flavor of the following sample is strictly equivalent to the one using the type-safe accessor above:

Using the tasks container API build.gradle jar { archiveName = "foo.jar" } build.gradle.kts tasks.named<Jar>("jar") { archiveName = "foo.jar" }

Note that since Kotlin is a statically typed language, it is necessary to specify the type of the task explicitly. Otherwise, the script will not compile because the inferred type will be Task , not Jar , and the archiveName property is specific to the Jar task type.

If configuration avoidance is getting in your way migrating and you want to eagerly configure a task just like Groovy you can do so by using the eager configuration API on the tasks container:

Using the tasks container API for eager configuration build.gradle jar { archiveName = "foo.jar" } build.gradle.kts tasks.getByName<Jar>("jar") { archiveName = "foo.jar" }

Working with containers in the Gradle Kotlin DSL is documented in detail in the Gradle user manual.

Knowing the type of a task If you don’t know what type a task has, then you can find that information out via the built-in help task. Simply pass it the name of the task you’re interested in using the --task option, like so: ❯ ./gradlew help --task jar ... Type Jar (org.gradle.api.tasks.bundling.Jar)

Let’s bring all this together by running through a quick worked example that configures the bootJar and bootRun tasks of a Spring Boot project:

Configuring Spring Boot using type-safe accessors build.gradle plugins { id 'java' id 'org.springframework.boot' version '2.0.2.RELEASE' } bootJar { archiveName = 'app.jar' mainClassName = 'com.example.demo.Demo' } bootRun { main = 'com.example.demo.Demo' args '--spring.profiles.active=demo' } build.gradle.kts plugins { java id("org.springframework.boot") version "2.0.2.RELEASE" } tasks.bootJar { archiveName = "app.jar" mainClassName = "com.example.demo.Demo" } tasks.bootRun { main = "com.example.demo.Demo" args("--spring.profiles.active=demo") }

This is pretty self explanatory. The main difference is that tasks are namespaced into the tasks container.

Now, for the sake of the example, let’s look at the same configuration applied using the API instead of the type-safe accessors that may not be available depending on the build logic structure, see the corresponding documentation in the Gradle user manual for more information.

We first determine the types of the bootJar and bootRun tasks via the help task:

❯ ./gradlew help --task bootJar ... Type BootJar (org.springframework.boot.gradle.tasks.bundling.BootJar)

❯ ./gradlew help --task bootRun ... Type BootRun (org.springframework.boot.gradle.tasks.run.BootRun)

Now that we know the types of the two tasks, we can import the relevant types — BootJar and BootRun — and configure the tasks as required. Note that the IDE can assist us with the required imports, so we only need the simple names, i.e. without the full packages. Here’s the resulting build script, complete with imports: