https://kotlinlang.org logo
Title
b

bdawg.io

09/06/2018, 1:27 AM
You can write a Gradle plugin that does everything instead and then you would just need to apply that plugin, not very recommended
g

gildor

09/06/2018, 2:08 AM
why “not very recommended”? Usually real binary plugin (you can have in buildSrc) much more pleasant to use than semi-dynamic script plugin applied from file
n

napperley

09/06/2018, 2:24 AM
Need to be very careful with what you include in buildSrc since it will be accessible in the entire project (includes multi module projects) aka global.
g

gildor

09/06/2018, 2:30 AM
Yes, it’s global, but if you encapsulated config in buildSrc to plugin, such plugin can be applied only to particular projects, so you have encapsulation, better code reusage and much better API (plugins dsl, support of extensions), not just include some block of code from a file
I would say that buildSrc + plugins is recommended way to share any configs or settings across projects
n

napperley

09/06/2018, 2:49 AM
Is there a official Gradle Kotlin DSL convention guide (similar to the Kotlin Coding Conventions - https://kotlinlang.org/docs/reference/coding-conventions.html )?
Not exactly the same, but covers some parts
From this document:
There are two key best practices that make it easier to work within the static context of the Kotlin DSL:
- Using the plugins {} block
- Putting local build logic in the build’s buildSrc directory
Also there is official Gradle docs, that applied together to Groovy and Kotlin: https://docs.gradle.org/4.10/userguide/organizing_gradle_projects.html#sec:build_sources
Use buildSrc to abstract imperative logic

Complex build logic is usually a good candidate for being encapsulated either as custom task or binary plugin. Custom task and plugin implementations should not live in the build script. It is very convenient to use buildSrc for that purpose as long as the code does not need to be shared among multiple, independent projects.