SpringBoot Gradle plugin: declare task dependencies for Gradle 7.0 Milestone 1

I'm using Gradle 7.0 Milestone 1, Spring Boot 2.4.2, and 2.4.2 for the spring-boot-gradle-plugin. I have a simple Gradle project with two subprojects (sub1, sub2). While sub2 is a regular Spring Boot project that depends on sub1, sub1 is used as a library. As described in https://spring.io/guides/gs/multi-module/ I disabled the bootJar task in the library subproject sub1.

During a build with Gradle 7.0 Milestone 1 I experience the errors shown below.

Example project: https://github.com/C-Otto/gradle7springboot

> Task :sub2:compileJava
Validation failed for task ':sub2:compileJava', disabling optimizations:
  - Task ':sub2:compileJava' uses the output of task ':sub1:bootJar', without declaring an explicit dependency (using Task.dependsOn() or Task.mustRunAfter()) or an implicit dependency (declaring task ':sub1:bootJar' as an input). This can lead to incorrect results being produced, depending on what order the tasks are executed.
Task ':sub2:compileJava' uses the output of task ':sub1:bootJar', without declaring an explicit dependency (using Task.dependsOn() or Task.mustRunAfter()) or an implicit dependency (declaring task ':sub1:bootJar' as an input). This can lead to incorrect results being produced, depending on what order the tasks are executed. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. Execution optimizations are disabled due to the failed validation. See https://docs.gradle.org/7.0-milestone-1/userguide/more_about_tasks.html#sec:up_to_date_checks for more details.

> Task :sub2:bootJarMainClassName
Validation failed for task ':sub2:bootJarMainClassName', disabling optimizations:
  - Task ':sub2:bootJarMainClassName' uses the output of task ':sub1:bootJar', without declaring an explicit dependency (using Task.dependsOn() or Task.mustRunAfter()) or an implicit dependency (declaring task ':sub1:bootJar' as an input). This can lead to incorrect results being produced, depending on what order the tasks are executed.
Task ':sub2:bootJarMainClassName' uses the output of task ':sub1:bootJar', without declaring an explicit dependency (using Task.dependsOn() or Task.mustRunAfter()) or an implicit dependency (declaring task ':sub1:bootJar' as an input). This can lead to incorrect results being produced, depending on what order the tasks are executed. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. Execution optimizations are disabled due to the failed validation. See https://docs.gradle.org/7.0-milestone-1/userguide/more_about_tasks.html#sec:up_to_date_checks for more details.

> Task :sub2:bootJar
Validation failed for task ':sub2:bootJar', disabling optimizations:
  - Task ':sub2:bootJar' uses the output of task ':sub1:bootJar', without declaring an explicit dependency (using Task.dependsOn() or Task.mustRunAfter()) or an implicit dependency (declaring task ':sub1:bootJar' as an input). This can lead to incorrect results being produced, depending on what order the tasks are executed.
Task ':sub2:bootJar' uses the output of task ':sub1:bootJar', without declaring an explicit dependency (using Task.dependsOn() or Task.mustRunAfter()) or an implicit dependency (declaring task ':sub1:bootJar' as an input). This can lead to incorrect results being produced, depending on what order the tasks are executed. This behaviour has been deprecated and is scheduled to be removed in Gradle 7.0. Execution optimizations are disabled due to the failed validation. See https://docs.gradle.org/7.0-milestone-1/userguide/more_about_tasks.html#sec:up_to_date_checks for more details.

Comment From: wilkinsona

It's a little odd that Gradle thinks that various tasks in sub2 are using the output of :sub1:bootJar as :sub1:bootJar is disabled. That feels like a bug in Gradle to me.

Gradle's confusion is due to the output location of bootJar and jar being the same. You can avoid the problem by configuring a classifier on bootJar:

bootJar {
    enabled = false
    classifier = 'boot'
}

https://github.com/spring-projects/spring-boot/issues/23797 will address this by configuring a classifier by default so I'm going to close this issue as a duplicate. I think it's probably also worth reporting this issue to the Gradle team to explore if it's correct that Gradle is considering disabled tasks during its validation process. If you open an issue, please comment here with a link to it so that we can follow along.

With all of that said, if you're using sub1 purely as a library, I wouldn't bother applying Spring Boot's plugin to it at all. Instead, I'd only use Spring Boot's dependency management as described in the documentation:

plugins {
    id 'org.springframework.boot' version '2.4.2' apply false
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}
group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'
repositories {
    mavenCentral()
}
dependencyManagement {
    imports {
        mavenBom org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES
    }
}
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
}
test {
    useJUnitPlatform()
}

Comment From: wilkinsona

I've opened https://github.com/spring-guides/gs-multi-module/issues/40 so that the guide can be corrected.

Comment From: C-Otto

Thank you! Adding the classifier helped. I'm looking into the other recommendation now.