You can write a Gradle plugin that does everything instead a kotlinlang #gradle

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

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.

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

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 )?

gildor

09/06/2018, 2:52 AM

https://guides.gradle.org/migrating-build-logic-from-groovy-to-kotlin/

👍 1

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.

#gradle Join Slack