Emil Kantis
02/27/2023, 8:26 AMVampire
02/27/2023, 8:41 AM...Compatibility
, and you can use the new lazy-enabled compileOptions
instead of the eager kotlinOptions
.
• Better not set the free compiler args unless you really want to overwrite all existing values but instead add to them
• When adding authenticated repository you might consider using the Gradle credentials support, so that you don't have the credentials in pain text in the build scriptEmil Kantis
02/27/2023, 9:14 AMHumphrey
03/13/2023, 1:22 AMVampire
03/13/2023, 1:26 AMHumphrey
03/13/2023, 8:32 AMVampire
03/13/2023, 8:33 AMplatform(...)
.Humphrey
03/13/2023, 8:36 AMEmil Kantis
03/13/2023, 8:38 AMVampire
03/13/2023, 8:42 AMI’ll take a look at it, do you have a link to documentation?
https://docs.gradle.org/current/userguide/platforms.html#sub:bom_import https://docs.spring.io/spring-boot/docs/current/gradle-plugin/reference/htmlsingle/#managing-dependencies.gradle-bom-support https://kantis.github.io/posts/gradle-improvements/
Humphrey
03/13/2023, 8:44 AMplugins {
id("org.springframework.boot") version "3.0.4" apply false
id("io.spring.dependency-management") version "1.1.0"
kotlin("jvm") version "1.8.0" apply false
kotlin("plugin.spring") version "1.8.0" apply false
}
subprojects {
plugins.apply("java-library")
plugins.apply("org.jetbrains.kotlin.jvm")
plugins.apply("org.jetbrains.kotlin.plugin.spring")
plugins.apply("io.spring.dependency-management")
dependencyManagement {
imports {
mavenBom(SpringBootPlugin.BOM_COORDINATES)
}
}
dependencies{
implementation()
}
}
But then I don't get implementation, it will be marked in red.
But dependencyManagement works...Vampire
03/13/2023, 8:48 AMsubprojects { ... }
, it is bad practice and has several drawbacks. Use convention plugins to share build configuration.
You only get type-safe accessors like implementation
when you apply plugins priority using the plugins { ... }
block. If you insist on following the bad practice you could use "implementation"(...)
instead.Humphrey
03/13/2023, 10:06 AMVampire
03/13/2023, 11:15 AMbuildSrc
or an included build, and then apply those convention plugins directly in the projects where you want these conventions to be in effect.
If you e.g. have 5 projects, where 3 are Java libraries and 2 are Java applications, you could e.g. have two convention plugins, one with the settings you want in Java library projects and one with the settings you want in Java application projects and then you apply the respecitve convention plugin in the respective projects directly.
Using allprojects { ... }
or subprojects { ... }
is so-called cross-project configuration which introduces project coupling which works against more sophisticated features like configure-on-demand or configuration cache, or project isolation, ...
And besides that it makes builds harder to understand and harder to maintain, as project's build script is not the source of truth, but you have to know and check places where you inject settings from outside.Humphrey
03/13/2023, 11:22 AMEmil Kantis
03/13/2023, 11:30 AMVampire
03/13/2023, 11:36 AMHumphrey
03/13/2023, 11:43 AMVampire
03/13/2023, 11:44 AMEmil Kantis
03/13/2023, 11:45 AM./gradle/plugins
, how does that compare to using buildSrc
or an included build?Humphrey
03/13/2023, 12:20 PMVampire
03/13/2023, 12:20 PMHumphrey
03/13/2023, 12:23 PMVampire
03/13/2023, 12:26 PMJohannesJendrik. Johannes is the last name. 😄 (I made that error myself too)
also puts convention plugins inI usually put them in, how does that compare to using./gradle/plugins
or an included build?buildSrc
./gradle/build-logic
.
Comparing to "an included build" is hard, because it most probably IS an included build.
buildSrc
vs. an included build is in the meantime for the most part a philosophical question.
Since Gradle 8, buildSrc
changed in some aspects to be even more similar to an included build.
But I personally still prefer included builds.
The most significant difference comes into play if you have several different convention plugins that are not applied everywhere.
If you have those in an included build in multiple projects in that build (or in multiple included builds), then only projects that use them get their classpath changed on a change in the plugin and thus only those need to be re-executed.
buildSrc
result is prepended to all build script classpaths and thus every change invalidates everything.
In small projects or if you only have convention plugins you anyway apply everwhere or almost everywhere, this difference is usually neglectible.
Another difference is, that with buildSrc
you get type-safe accessors for the plugins for usage in Kotlin DSL, while coming from an included build (except when using a little hack) you have to use their ID to apply them, which I don't see as major drawback. You can also add them to a version catalog and use it from there.
Another difference where you must use buildSrc
due to the classpath prepending is, if you have the rare need to monkey-patch a plugin class. This only works when doing it in buildSrc
, but I'm not going to elaborate on that here as you hopefully never need that.