This message was deleted.

buildSrc

is no longer a recommended way to do that. It's non-standard and not compatible with incremental builds. Please use version catalogs. TL;DR - It's a file that lives in

gradle/libs.versions.toml

and centrally declares your dependencies. Version Catalogs: https://docs.gradle.org/current/userguide/platforms.html

I'd go with convention plugins even with 3 modules, you won't regret it later

If you have the time, and the project will keep growing, I agree with @melix. Convention plugins are 💯

They don't really need much more time and I even use them for single-project builds to split it up by topic and not have one 3000 line build with testing, PIT testing, publishing, ..... 🙂

(shameless plug: if you want to start correct right away, use Micronaut instead of Spring Boot) 🥷

@Vampire where can I read this to not use the Spring dependency management plugin? Thank

Example convention plugins from my open source sample app: • Gradle Convention Plugins: https://github.com/handstandsam/ShoppingApp/tree/main/convention-plugins • How to define IDs: https://github.com/handstandsam/ShoppingApp/blob/main/convention-plugins/build.gradle.kts#L29-L50 • How to include them in the build: https://github.com/handstandsam/ShoppingApp/blob/aa6dba0129d3e15b74bd3d16ac3ffdab9ab8fa49/settings.gradle#L32C1-L36C2 • How to use it by ID https://github.com/handstandsam/ShoppingApp/blob/main/models/build.gradle.kts#L2

where can I read this to not use the Spring dependency management plugin? Thank

https://linen.dev/s/gradle-community/t/2579116/what-is-the-proper-way-to-apply-a-bom-in-a-library-project-i#a7d4a60a-ab60-48dc-8477-f3f4462d1e6a

I would still use the buildSrc which was not recommended like @Sam Edwards says?

That was a misinterpretation. What he meant was, that it is not recommended to use some

Versions

class or similar to centrally manage versions in

buildSrc

, but instead you should use a version catalog for that. Using convention plugins in

buildSrc

or - what I prefer - in an included build is still the proper way to centralize and organize build logic.

Is there an example project for this other than here?

There are many. For example https://github.com/jjohannes/idiomatic-gradle, but that is pretty sophisticated, and probably indeed a bit more than you should use in a smaller project, but still interesting to look at and learn from.

Maybe with Java and Kotlin support, because the modules could be either java or kotlin modules.

You will simply have a convention plugin for java projects and one for kotlin projects. If there are common things, you maybe have another one with the common things that is then applied by the other two, ...

I use the included build instead of

buildSrc

because on larger projects you can precompile them and us binaries, but it's the same thing to use either if you don't have that need. I also just like the clean separation.

It's not the same. Since Gradle 8

buildSrc

was made a bit more like an included build like not always running tests and so on. But there are still significant differences.

buildSrc

is always built and prefixed to the build script class path, overwriting any versions and changing class path of all projects and thus making things out-of-date. An included build is only built if actually used, and it is a normal dependency that is conflict resolved with other things in the same build script class path. And if you devide the build logic into multiple projects, they produce different jars, so just invalidate projects where they are actually used, not always the whole build, and so on. For small builds this is most probably all neglectable, but in bigger builds with many different projects that need different of the build logic plugins, this can indeed become a topic.

First of all: Thank you all for your input. I am in the process of setting up the project as an example and am facing some problems. First I have the following structure:

├── api
│   ├── src
│   │   └──...
│   └── build.gradle.kts
├── buildSrc
│   ├── src
│   │   └──main
│   │       └──kotlin
|   |          └──common-convention.gradle.kts
|   |          └──spring-convention.gradle.kts
│   └── build.gradle.kts
│   └── settings.gradle.kts
├── domain-model
│   ├── src
│   │   └──...
│   └── build.gradle.kts
├── integration-service
│   ├── src
│   │   └──...
│   └── build.gradle.kts
└── settings.gradle.kts

• The first problem, I am trying to add detekt as a plugin and dependency in my

common-convention.gradle.kts

, for this I have added the following dependency in my

build.gradle.kts

:

implementation("io.gitlab.arturbosch.detekt:detekt-gradle-plugin:1.23.1")

. In the

common-convention.gradle.kts

I've added the following.

// common-convention.gradle.kts
plugins {
    kotlin("jvm")
    id("io.gitlab.arturbosch.detekt")
}

java {
    sourceCompatibility = JavaVersion.VERSION_17
}

repositories {
    mavenCentral()
}

detekt {
    buildUponDefaultConfig = true // preconfigure defaults
    allRules = true // activate all available (even unstable) rules.
}

dependencies {
    detektPlugins("io.gitlab.arturbosch.detekt:detekt-formatting")
    runtimeOnly("io.github.microutils:kotlin-logging-jvm:3.0.5")
}

Then I've added the common conventions in api subproject as plugin with it's id. When I run detekt it throw the following error:

> Could not resolve all files for configuration ':api:detektPlugins'.
   > Could not find io.gitlab.arturbosch.detekt:detekt-formatting:.
     Required by:
         project :api

I've analyzed the dependencies and in the api module, all detekt dependencies are included, but I can not run the plugin. Any idea why? • Another thing is, like you see above I've

io.github.microutils:kotlin-logging-jvm:3.0.5

as dependency in the common conventions. What I did is adding this dependency in the version catalog in the setting.gradle.kts, but I cann not access this lib, only in the build.gradle.kts. Is there a proper way to do that? • Last but not least, I'm getting this kind of error

Argument for @NotNull parameter 'buildSrcModuleNode' of org/jetbrains/plugins/gradle/service/project/GradleBuildSrcProjectsResolver.addBuildSrcToBuildScriptClasspathData must not be null

Where I've no clue why it shows up, and that only sometimes after reload project. Thanks in advance!!

You depend on

io.gitlab.arturbosch.detekt:detekt-formatting

for

detektPlugins

but you did not specify a version

Awesome, thank you for that help! For the last point there is already a task: https://youtrack.jetbrains.com/issue/IDEA-325846