migrate Gradle config to use to buildSrc convention plugins

[aSemy]

Prep for #29

• Created the buildSrc project
• Created a shared repository definition file, so it's easier to set the repositories available for buildSrc and the main project
• moved the common Kotlin configuration to kotlin-jvm.gradle.kts, and applied it to the subprojects
• the same for the Maven publishing config
• libs.versions.toml is still used to define versions - but Gradle plugins versions are now defined in buildSrc/build.gradle.kts. This is the only place the versions need to be defined - once they are, the plugins can be imported without a version in convention plugins, or build scripts (in fact Gradle will complain if the version is set again).
• bumped the JDK version to 11, and told JitPack to use JDK 11

[serras]

Thanks for your contribution! I’m not that knowledgeable with Gradle, so may I ask what are the benefits of this approach? Is this layout recommended or better to what we have?

[serras]

Oh, I see now this is an intermediate step to building an actual Gradle plug-in

[aSemy]

No problem! I'm happy to explain as much as you want :)

The way KopyKat is structured now is more like how a Maven project might be configured, with a 'parent' config file that all subprojects inherit from. However, Gradle is different - config can be applied through 'composition', which is a little more complicated, but ends up being the best-of-both-worlds!

For example, it's easy to create a convention for Maven publishing: buildsrc.conventions.maven-publish. But not all projects will get published in the same way, for example, a Gradle plugin (there's a specific Gradle plugin for publishing to the Gradle Plugin Portal). Perhaps in future, the same is also true of a test-utility project, or an integration test project - they don't need to be published. Because the Maven publishing config is in a separate plugin, it can be applied only when it's requested, rather than on all subprojects.

Here's a bit of link dumping, if you'd like to read more

• https://github.com/liutikas/gradle-best-practices
• https://stackoverflow.com/a/71892685/4161471
• https://melix.github.io/blog/2021/12/composition-in-gradle.html

[serras]

@aSemy is this ready to merge?

[aSemy]

Yes