https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
There are many possibilities, depending on details. You can for example indeed use a version catalog, and require that the consuming project has an according entry in his version catalog, or you can also publish your version catalog and let the consumer use it on his project and again use it then. If you want to fix control it and not let the consumer decide, just have a constant somewhere that you use.
b
so the basic issue is that the convention plugin architecture requires me to define plugins and their versions in it's build.gradle.kts file 
dependencies {
implementation(libs.kotlin.jvm)
implementation(libs.kotlin.kapt)
implementation(libs.gradle.versions)
implementation(libs.kotlin.spring.boot)
implementation(libs.spring.boot)
implementation(libs.spring.boot.dependency.management)
}
the kotlin version is defined in settings.gradle.kts 
dependencyResolutionManagement {
versionCatalogs {
create("libs") {
version("spring", "3.2.2")
version("kotlin", "1.9.22")
library(
"spring-boot",
"org.springframework.boot",
"org.springframework.boot.gradle.plugin"
).versionRef("spring")
library(
"spring-boot-dependency-management",
"io.spring.dependency-management:io.spring.dependency-management.gradle.plugin:1.1.4"
)
library(
"kotlin-spring-boot",
"org.jetbrains.kotlin.plugin.spring",
"org.jetbrains.kotlin.plugin.spring.gradle.plugin"
).versionRef("kotlin")
library(
"kotlin-jvm",
"org.jetbrains.kotlin.jvm",
"org.jetbrains.kotlin.jvm.gradle.plugin"
).versionRef("kotlin")
library(
"kotlin-kapt",
"org.jetbrains.kotlin.kapt",
"org.jetbrains.kotlin.kapt.gradle.plugin"
).versionRef("kotlin")
library(
"gradle-versions",
"com.github.ben-manes.versions:com.github.ben-manes.versions.gradle.plugin:0.49.0"
)
}
}
now I also want to access the kotlin version in my convention plugin
implementation(kotlin("reflect", kotlinVersionHere))
how I understand it: the version catalog for the plugin is not accessible in the project using it
v
Exact
b
since the plugin is in the buildSrc? build stage
so I'm unsure how to use constants in that case
they will also be isolated, right?
v
If it is about 
buildSrc
, you could simply use a version catalog as TOML file (recommended / preferred anyway) and use that TOML as version catalog in both builds, the 
buildSrc
build and the main build, then you can use the version catalog entries as you intended to.
Without that and still wanting to use the version from the version catalog, you could for example create some properties file from the version catalog entry and then use that properties file in the convention plugin.
Btw. you should not use the Spring dependency management plugin. It is an obsolete relict from times when Gradle did not have built-in BOM support, by now does more harm than good, and even its maintainer recommends not to use it anymore, but instead the built-in BOM support using 
platform(...)
b
it's still generated using their start.spring.io website, thanks for the heads up
when going for the toml approach, where do I need the define the version catalog? can I do it in the convention plugin somehow so I don't need to do it in every project that depends on the convention plugin?
v
I know it is, doesn't change anything in what I said 🙂
And their docs show both options
It is in the settings script, so it is either way only one-time
b
ok, so in each project's settings.gradle.kts that uses the convention plugin?
v
You can for example put it to 
gradle/libs.versions.toml
which is the conventional place and thus gets used automatically and then include it explicitly in 
buildSrc/settings.gradle.kts
, then this is the only place where you include it explicitly
ok, so in each project's settings.gradle.kts that uses the convention plugin?
You only have one
settings script is per build, not per project. and as you have the convention plugin in 
buildSrc
you can only use it in its owning build. So you only need it in one place as described
b
I'm using a composite build so I don't think I can go for that
as in: no top level settings.gradle.kts
v
You said you use 
buildSrc
, not an included build
But yeah, if you have a composite build and have multiple builds in it that use the convention plugin, you might need it in all of them.
b
I meant that more as the build step mechanism similar to that
ok, thank you for your time and help 🙂
v
If the convention plugins is in an included build too, you can of course also make a settings plugin that does the configuration and then just apply that settings plugin
b
ah, I see
thank you
v
I meant that more as the build step mechanism similar to that
Yeah, that's a bit unlucky, as it might sometimes change the answers, as there are slight differences. 😉
t
Doesn't Kotlin ensures version alignment by default? (so you don't need to specify an explicit version) AFAIK, it takes the version from 
kotlin.coreLibrariesVersion
that defaults to the plugin version.
b
that'd be great; suppose it's done via the kotlin() method? need to fix my decompiler
t
Not even by that method. The 
kotlin()
method will generate a 
groupId:artifactId
without version, and an action fixes the missing version before resolution: https://github.com/JetBrains/kotlin/blob/d04b3050c005701bf6d237c52454c995622a60c9/[…]etbrains/kotlin/gradle/internal/KotlinDependenciesManagement.kt
🙌 1
j
@Thomas Broyer there is a bom too
anyway, you don’t even need the Kotlin method. You can write any kotlin dependency without version and the plugin will add it. 
testImplementation(“org.jetbrains.kotlin:kotlin-test”)
Additionally, KGP exposes a 
getKotlinVersion()
function too
b
that's neat, thanks for the additional information
5 Views
Open in Slack
PreviousNext
Powered by