Nick Kleban
11/20/2024, 8:19 AMbuild-logic
with convention plugins as kts
files inside, instead of kt
that I usually saw in the other projects. And now there is like 3 ways to write a convention plugins.
• in buildSrc as kts
• in included project as kt
• in included project as kts
Is there any best one and what benefits and downsides for each?Vampire
11/20/2024, 1:33 PM...gradle.kts
files), they can be written as precompiled script plugins in Groovy (the things in ...gradle
files), they can be written as legacy script plugins in Groovy or Kotlin (the things you apply with "from" which you should practically never use), they can be written as normal binary plugins in any JVM language (for example in a .java
file, or a .groovy
file, or a .kt
file, or any other JVM language you want to use).
All of these (except for the legacy script plugins) can be put to any place where you want them to be, in buildSrc
, in an included build, in a completely separate build that you publish and then use from the publication location.
Now multiply those possibilities. 😄Vampire
11/20/2024, 1:37 PMinit
generates depends on the options you give it, but I don't think it ever generated .kt
files in build logic but I might be wrong. Whether you use what it gave you as-is or change any detail is up to you. For local build logic and convention plugins I personally would always use an included build unless I need to do something that only works with buildSrc
like monkey-patching 3rd party plugin's classes.
Since Gradle 8.0 quite some of the downsides of buildSrc
compared to an included build were eradicated, making them more similar to an included build, but there are still a few differences. But in a small or probably even mid-sized build you will most probably barely notice much difference in usability and performance.