Gradle 8.1.1 and Spring Boot Plugin - Unresolved reference: BootRun

Hi,

I’ve created a simple application based on creator from site Spring Initializr with selected options:

  • Project: Gradle - Kotlin
  • Language: Java
  • Spring Boot: 3.1.1
  • Packaging: JAR
  • Java: 17

When I run my app with command:

gradlew build

It’s OK - build is successfull. Now, I want to add some configuration for Spring Boot plugin:

tasks.named<BootRun>("bootRun") {
    mainClass.set("com.example.demo.DemoApplication")
}

Build is not successfull:

  Line 27: tasks.named<BootRun>("bootRun") {
                       ^ Unresolved reference: BootRun

  Line 27: tasks.named<BootRun>("bootRun") {
                                           ^ Type mismatch: inferred type is () -> ??? but Class<TypeVariable(S)!>! was expected

  Line 28:      mainClass.set("com.example.demo.DemoApplication")
            ^ Unresolved reference: mainClass

Here is my full build.gradle.kts file:

plugins {
	java
	id("org.springframework.boot") version "3.1.1"
	id("io.spring.dependency-management") version "1.1.0"
}

group = "com.example"
version = "0.0.1-SNAPSHOT"

java {
	sourceCompatibility = JavaVersion.VERSION_17
}

repositories {
	mavenCentral()
}

dependencies {
	implementation("org.springframework.boot:spring-boot-starter")
	testImplementation("org.springframework.boot:spring-boot-starter-test")
}

tasks.withType<Test> {
	useJUnitPlatform()
}

tasks.named<BootRun>("bootRun") {
	mainClass.set("com.example.demo.DemoApplication")
}

Regards

It is a Kotlin script, so quite similar to a Java source file.
If you want to use a class, like BootRun you either have to use the fully-qualified name, or import the class at the top of the script.

The better, more idiomatic, and nicer approach though is to just use the generated type-safe accessor, so it should just be

tasks.bootRun {
   ...
}

Your solution works. I thought that the new way to use a Spring Boot plugin in a Kotlin script is that which they mention on the docs site Spring Boot Gradle Plugin Reference Guide - without additional manual imports.
Thank you very much for help.

In Groovy it is better to work with tasks.named, as there the accessor breaks task-configuration avoidance due to backwards compatibility.

I guess the Spring guys either wanted it consistent and thought the IDE hint to import the class is enough, or they are not aware that in Kotlin the name-accessor leverages task configuration avoidance properly.

1 Like