Migrate to build-logic convention plugins

[makeevrserg]

Summary

PR introduces a build-logic included build with convention plugins, replacing previous configuration approach. In addition, new setup will help to make project gradle plugins looks minimal, allows to configure the plugin-by plugin

Changes

• Added build-logic included build with convention module containing:
  • id("net.elytrium.checkstyle") - Default configuration for checkstyle
  • id("net.elytrium.java.version") - Configuration for JavaVersion
  • id("net.elytrium.licence") - Configuration for licences files
  • id("net.elytrium.module.info") - Configuration for version/name of modules
  • id("net.elytrium.publish") - Configuration for publish into maven
  • id("net.elytrium.revision") - Provider for current revision number
  • id("net.elytrium.spotbugs") - Configuration for spotbugs
• Removed allprojects/subprojects blocks, which considered anipatterns, from root build.gradle.kts

[mdxd44]

Are changes like these really necessary? Personally, I can't stand Kotlin, and to me this kind of stuff just bloats and slows down the build system while making further changes more difficult. There used to be about three files needed for the build; now there are more than ten. For what, exactly? The end result is still the same.

And honestly, did you really spend your own time on this, or did you just tell Claude to do it for you?

[makeevrserg]

Are changes like these really necessary? Personally, I can't stand Kotlin, and to me this kind of stuff just bloats and slows down the build system while making further changes more difficult. There used to be about three files needed for the build; now there are more than ten. For what, exactly? The end result is still the same.

And honestly, did you really spend your own time on this, or did you just tell Claude to do it for you?

Well, it seems better than put everything into one build.gradle, isn't it?

If the complain is about kotlin, it, of course, can be written with java, but I made it the way I know how to do it

Bloats, slow down?

The build system actually becomes more clear and amount of anti patterns are reduced

Yes, I did it myself. You can try it yourself. I don't think any llm is capable of converting groovy to build convention with the same output result

[makeevrserg]

Btw build.gradlre of plugin module literally unreadable and difficult to maintain, even if you say otherwise, it's still fact. And build convention here would help to make it easy to read and maintain

[mdxd44]

Btw build.gradlre of plugin module literally unreadable and difficult to maintain, even if you say otherwise, it's still fact. And build convention here would help to make it easy to read and maintain

That's because the entire mappings generator is located there. I've already fixed this in a separate branch, but unfortunately it won't be merged into master anytime soon.
https://github.com/Elytrium/LimboAPI/blob/1.2.0/plugin/mappings_generator.gradle

[mdxd44]

Well, it seems better than put everything into one build.gradle, isn't it?

Also, in that branch, the total line count is 39 + 67 + 107 = 213, excluding the mappings generator

[makeevrserg]

Yes, I've seen it. And this fix is another popular antipattern, which contains whole logic inside one single file.
This mapper can easily be splitted into different extensions, tasks and plugin. And it can be done in a right way using build convention, which is standard way of configuring difficult Gradle scripts

[mdxd44]

By that logic, this whole project is just one big anti-pattern and we should split every class down into 10 classes by 20 lines each

[makeevrserg]

You are exaggerating now. I just follow logic of clean code and best ways of Gradle practices

[mdxd44]

Fine.

Anyway, @UserNugget, if there are no suggestions or comments, feel free to merge

[UserNugget]

Looks pretty overcomplicated, Velocity implemented it way better and readable
Yet i think splitting it that much is not necessary even if it's considered as best practice.

[makeevrserg]

Yeah, can be done this way
It may seem overcomplicated, yes. On the other hand, having whole repository with own gradle scripts may make like easier, applying plugins from there
In addition, consider that via build convention, build.gradle of plugin module can be refactored into much smaller chunks, which will make it easier to maintain