Skip to content

Gradle plugin: declare task dependencies for Gradle 7.0 Milestone 1 #25126

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
C-Otto opened this issue Feb 6, 2021 · 3 comments
Closed

Gradle plugin: declare task dependencies for Gradle 7.0 Milestone 1 #25126

C-Otto opened this issue Feb 6, 2021 · 3 comments
Labels
status: duplicate A duplicate of another issue

Comments

@C-Otto
Copy link

C-Otto commented Feb 6, 2021

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.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 6, 2021
@wilkinsona
Copy link
Member

wilkinsona commented Feb 6, 2021

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'
}

#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()
}

@wilkinsona wilkinsona added status: duplicate A duplicate of another issue and removed status: waiting-for-triage An issue we've not yet triaged labels Feb 6, 2021
@wilkinsona
Copy link
Member

I've opened spring-guides/gs-multi-module#40 so that the guide can be corrected.

@C-Otto
Copy link
Author

C-Otto commented Feb 7, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: duplicate A duplicate of another issue
Projects
None yet
Development

No branches or pull requests

3 participants