https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
g
You could switch to 
compileOnly
for spring boot plugin in 
buildSrc/build.gradle.kts
and still try to apply it with 
plugins { id("org.springframework.boot") }
in the convention plugin. It will require to apply relevant spring boot plugin for each relevant project but you shouldn't have whacky classpath issues that way. Of course, if you configure spring boot plugin from convention plugin (like calling 
springBoot { buildInfo() }
) its api should be compatible and it's on you to check if it is. Also if you don't override some dependencies versions using properties don't apply 
io.spring.dependency-management
, just use normal gradle BOM/platform support. Also, I'd recommend to avoid 
apply(plugin = "..")
and use 
plugins { .. }
instead. You'll likely have to do same 
compileOnly
trick for kotlin plugin (and same for kotlin spring subplugin), especially if you kotlin plugin version differs from 
embeddedKotlinVersion
)
Another way to go is to have several convention plugins for different spring boot versions in different subprojects, not sure if it would work with 
buildSrc
but it works quite fine with included builds
t
From what you say, it seems to me that it is far from ideal to handle this within buildSrc. Furthermore, 
have several convention plugins for different spring boot versions in different subprojects,
; as far as I understand this will not be possible because that would mean to have multiple versions of the same plugin into 
buildSrc/build.gradle.kts
. I’ll give a try with included build 👍
g
I'm not sure if it's possible with buildSrc because of its special place in the build classpath. But with included build you could easily have 
build-logic/boot26/build.gradle.kts
and 
build-logic/boot27/build.gradle.kts
. But maybe you could use the same plugin like 2.7.x and just vary platform version between projects that use different spring boot version
I'd try later first since boot plugin changes could be rather minor
t
Following the Gradle sample with composite builds, they seem to have:
Copy code
platforms/plugins-platform define api version constraints for kotlin and spring plugins
build-logic/kotlin-library 
build-logic/spring-application
I should be able to achieve something similar:
Copy code
// platforms/plugins-platform/build.gradle.kts
dependencies {
    constraints {
        api("org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.8.10")
        api("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.10")
        api("org.jetbrains.kotlin:kotlin-allopen:1.8.10")
    }
}

// build-logic/spring-boot-application/src/main/kotlin/com.example.spring-boot-application.gradle.kts
// just define common implementation to be used
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("org.springframework.boot:spring-boot-starter-jooq")
}

// applications/some-app-on-boot26/build.gradle.kts
plugins {
    id("com.example.spring-boot-application")
    id("org.springframework.boot") version "2.7.8"
}
Next step is understanding difference between spring-dependency-management plugin and spring bom (you talked about it earlier). Good start seems to read this blogpost Bonus question, do you have any experience with managing gradle dependencies with toml file? My first concerns are: • IntelliJ IDEA support • Github dependabot support • any caveat, pros and cons vs using pure gradle
g
Next step is understanding difference between spring-dependency-management plugin and spring bom (you talked about it earlier).
Spring dependency management plugin is a plugin that could apply bom using legacy mechanisms for old gradle versions before native bom/platform support. So instead of
Copy code
dependencyManagement {
  imports { 
    mavenBom(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
  }
}
you just use
Copy code
dependencies {
  implementation(platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES))
}
If you need to override some dependency version you could use usual dependency constraints.
Bonus question, do you have any experience with managing gradle dependencies with toml file?
If you mean version catalog in toml format than yes. I use it quite a lot. IDEA support still not very great: • after adding/removing alias to the catalog you'll need to reload/reimport to have completion for updated aliases • click/ctrl+b on 
libs.some.thing
will lead you to generated code and not the catalog itself I don't remember if dependabot tries to suggest catalog modifications but that's useless since real versions are determined after dependency resolution, so versions written in build files and/or catalogs could differ from real ones. There were plugins to upload dependency resolution results for dependabot to analyze but I haven't tried them yet. What do you mean by "vs using pure gradle" idk, there's a lot of methods people use to manage deps
t
I was just wondering why people use toml, but I guess I need to dive a bit in it. FYI, toml seems to be supported by dependabot. I understand that static analysis of this file does not resolve dependencies. (I guess dependabot execute static analysis). Nevertheless, with Gradle highest-version resolution (<> Maven nearest to root resolution) ; it seems to be a good start on my side.
Anyway, thank you for your help, I’ve learned a lot! Appreciated 🙂
g
Ohh, they just merged support for catalogs a week ago, great. Thanks for the info 🎉
🤗 1
9 Views
Open in Slack
PreviousNext
Powered by