This message was deleted.

I strongly recommend against doing that. Especially with Kotlin DSL legacy script plugins like these are sub-optimal, as you for example cannot use

plugins { ... }

and do not get type-safe accessors generated. Alternatively to

buildSrc

you could put the build logic into a dedicated included build, or into a dedicated subproject in

buildSrc

.

Hmm, included build would require another submodule right? And what do you mean when u say dedicated subproject in buildSrc. From what I understand both approaches would imply splitting the build logic outside the specific submodule right?

Yes, it would involve a different module all together. At first it may seem like a good bit of extra overhead, but after a while you’ll likely find yourself in the herding elephants land when thinking about using

apply(from = string)

. As Vampire suggests, there’s a lot of items in the Kotlin DSL that don’t work so great when you try and go that path. On top of that, as the DSL for Kotlin matures more, legacy constructs get deprecated or removed, changes in the include build are much simpler to deal with than trying to find all the build scripts that you’ve included by using the apply method.

Hmm, included build would require another submodule right?

Depends on what you mean when you say "submodule". If you mean Git submodule, no, you can have multiple builds in one repository just like with

buildSrc

which is "almost" an included build just with some special handling and some special behavior.

And what do you mean when u say dedicated subproject in buildSrc.

Each and every build is a potential multi-project build, you just need to do an

include(...)

in its settings script.

buildSrc

is not different in that regard. That was just if your concern is, that you do not want to mix the build logic for that one project with the build logic for all other projects code-structure-wise.

From what I understand both approaches would imply splitting the build logic outside the specific submodule right?

Well, yes and no. Logically and build-wise yes. Physically you could also have in your project

foo

a folder

foo-build-logic

with the build building those convention plugins and include that build from your settings script.

Ya I did know that

apply from

was a bad approach but wasn't sure on how composite builds would apply. Thanks will explore how to setup composite builds for my needs ✌️