Spring Boot Gradle plugin adds an unwanted dependency on a library jar

[Quinteger]

Let me illustrate the issue with an exaple. I've created a small sample project:

gradle-sandbox
├─lib
│ ├─...
│ └─build.gradle.kts
├─consumer
│ ├─...
│ └─build.gradle.kts
└─settings.gradle.kts

Contents of settings.gradle.kts:

rootProject.name = "gradle-sandbox"
include("consumer")
include("lib")

Now, let's assume that the lib project is a Spring Boot library that I want to consume in the consumer project. I add the plugin to lib/build.gradle.kts:

plugins {
    id("java")
    `java-library`
    id("org.springframework.boot") version "3.2.2"
}

and I add the project dependency in consumer/build.gradle.kts

dependencies {
    implementation(project(":lib"))
}

It appears in the modules view and everything works fine. I can write code in lib and use it in consumer.

Then, I realize that I don't really need the uber jar in my lib project (because it's a library) and I need the regular jar with an empty classifier instead (because I want to publish it to an internal repo, for example). Inspired by this section of the reference documentation, I add the following to lib/build.gradle.kts:

tasks.named<BootJar>("bootJar") {
    enabled = false
}

tasks.named<Jar>("jar") {
    archiveClassifier = ""
}

Suddenly, now the consumer module not only depends on the sources of the lib module, but also on its jar output:

Which becomes a huge problem in development and causes all sorts of issues like duplicated Liquibase changelogs.

Oddly enough, the issue can be resolved by setting a non-empty classifier on either of the tasks. So adding archiveClassifier = "12345" to the BootJar closure or replacing the one in Jar closure both works and removes the jar from the classpath. And since I don't need the BootJar task anyway I can add any random classifier to it and call it a day. But this still indicates a potential bug.

[wilkinsona]

Spring Boot's plugin shouldn't be applied to the library project as it's not a Spring Boot application, it's just a library. If you wish, you can still use Spring Boot's dependency management by following the instructions in the documentation.

If you have any further questions, please follow up on Stack Overflow. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.