Cross project configuration

Help/Discuss
1

Hello guys, I was reading the gradle documentation, and I saw that is not recomended use cross project configuration to share build logic inside a multi module project.
Instead of subprojects DSL, the documentation recomends use buildSrc.
My project with buildSrc:

├── settings.gradle.kts
├── buildSrc
│   ├── build.gradle.kts
│   └── shared.settings.gradle.kts
├── app
│   └── build.gradle.kts
├── adapters
│   └── build.gradle.kts

My project using subprojects DSL:

├── settings.gradle.kts
├── build.gradle.kts
├── app
│   └── build.gradle.kts
├── adapters
│   └── build.gradle.kts

where, app module is mainly pure kotlin with some test dependencies, and adapters is my ‘dirty’ module, where I have springboot, database, rest client libs and so on. My questons is, for this application, buildSrc is the best way to share common dependencies (junit for example) and plugins (idea, jacoco, kotlin.jvm, ktlint)? When subproject DSL is preferred instead of buildSrc?
I have been creating a root build.gradle.kts and configured the commons plugins and dependencies using the subprojects DSL, instead of buildSrc strategy.
Obs: I don’t need a common custom task or a common custom plugin for this project.

2

that is not recomended use cross project configuration to share build logic

Correct you should never use any means of cross-project configuration like subprojects { ... }, allprojects { ... }, project("...") { ... }, … and not even get information from the model of a different project.
This immediately introduces project coupling, which works against some more sophisticated Gradle features and optimizations.

the documentation recomends use buildSrc.

Yes, either that, or - what I prefer if possible - an included build.

My project with buildSrc:

What’s the intention of shared.settings.gradle.kts?
This file does not really make any sense at that place.
Well, unless you then use it with “apply from” which is again something completely different that is called “legacy script plugin” and is also highly discouraged and has nothing to do with buildSrc.

to share common dependencies (junit for example)

For sharing a couple of dependencies, you can also simply use a bundle in a version catalog that you then use in the projects.

plugins (idea, jacoco, kotlin.jvm, ktlint)?

Yes, for common build logic you should use a convention plugin.
Whether you put it into buildSrc, or an included build, or even publish it to use it in multiple projects does not matter much and is more a question of preference.

When subproject DSL is preferred instead of buildSrc?

Never!

I have been creating a root build.gradle.kts and configured the commons plugins and dependencies using the subprojects DSL, instead of buildSrc strategy.

Never do that!
See above.

Obs: I don’t need a common custom task or a common custom plugin for this project.

That’s irrelevant

1 Like