Consider moving to build.gradle.kts

[Martmists-GH]

Gradle's official documentation, as well a variety of other sites, are moving to build.gradle.kts as the default.

The kotlin build script format feels much more similar to java and/or kotlin than the current groovy syntax. This is good, because these two languages are used much more frequently in modding, while the latter isn't used at all (to my knowledge).
Additionally, kotlin build scripts provide type hints and full syntax highlighting in IntelliJ, and are usually more verbose in their errors to help identify any problems users may encounter in their build scripts.

The main downside this change would have on this repo is that a large chunk of the gradle.properties file would be better off in a libs.versions.toml file, rather than accessing them through project.extra["..."]. While this is not necessarily a downside, it does add a small amount of complexity to using the toolchain.

[TelepathicGrunt]

I think what would help people decide which they like more is seeing an mdk example using this to compare the current mdk with

[Martmists-GH]

For reference, I made a sample port to the kotlin build script at https://github.com/Martmists-GH/MDK-kts
I believe it should be 100% identical, but if there's anything inconsistent feel free to point it out.

[TelepathicGrunt]

How well are the Eclipse and Eclipse Plugins support for this kind of buildscript? The MDK is ideally suppose to be maintainable and easily usable for a wide range of setups people may have one Eclipse and Intellij

[thiakil]

• groovy is much closer to Java than it is to kotlin (Java code can be copy pasted to groovy and be 90% syntax compatible)
• idea can do groovy type hints and highlighting, it just needs the all distro, which there is now an mdk pr for
• kotlin script syntax requires extra syntax fuss for zero real benefit
• kotlin scripts have zero syntax highlighting until after the first import (good luck if you have any errors)
• there are many more snippets and examples around for groovy scripts, especially in a minecraft context

[shartte]

kotlin scripts have zero syntax highlighting until after the first import (good luck if you have any errors)

I am a Kotlin fanboy but this particular issue is the reason I do not use Kotlin buildscripts anywhere.

[Martmists-GH]

How well are the Eclipse and Eclipse Plugins support for this kind of buildscript? The MDK is ideally suppose to be maintainable and easily usable for a wide range of setups people may have one Eclipse and Intellij

Eclipse Buildship added Kotlin DSL support late 2023.

kotlin script syntax requires extra syntax fuss for zero real benefit

Kotlin build scripts benefit from being less magic-y. Groovy suffers from not differentiating between variables, functions and strings cleanly. Some examples from this repo:

• minecraft.accessTransformers.entry public net.minecraft.client.Minecraft textureManager # textureManager here everything after entry is a single string
• expand replaceProperties here replaceProperties is a variable, with no syntactic difference from the former

kotlin scripts have zero syntax highlighting until after the first import (good luck if you have any errors)

Groovy suffers from the same problem, but this shoudldn't be a concern as the MDK is designed to always load as-is with no errors. Modifications will still show syntax highlighting afterwards, even if they cause errors. Even supposing this were a problem, kotlin build scripts tend to be more verbose in regards to error reporting compared to groovy, in my experience.

there are many more snippets and examples around for groovy scripts, especially in a minecraft context

I'd argue that most of these are usually dependencies and not any complex logic, as you'd see on e.g. the Gradle Documentation. For most users, the difference between implementation("x") and implementation 'x' shouldn't matter much (the former should even still work on Groovy), but for advanced users, most relevant documentation uses the Kotlin DSL.

[Matyrobbrt]

Kotlin build scripts benefit from being less magic-y. Groovy suffers from not differentiating between variables, functions and strings cleanly. Some examples from this repo:

That's not correct, strings are clearly differentiated using ' (and respectively " for GStrings). The example provided is incorrect, all strings must be implicit, and even if they weren't, the call chain for implicit parenthesis (for a b c d) is a(b).c(d).

I'd argue that most of these are usually dependencies and not any complex logic, as you'd see on e.g. the Gradle Documentation.

Not really, most examples and linked code you'll find browsing the Forge forums and Discord servers are in Groovy, and those vary from creating new sourcesets (like datagen sourcesets, or api sourcesets), new runs, new configurations, hacks for certain configurations and IDEs (used for eclipse historically for ages). The syntax for creating and using a custom configuration, and for creating sourcesets and wiring their dependencies is quite different between Groovy and Kotlin.

As for the other parts of your comment,

This is good, because these two languages are used much more frequently in modding, while the latter isn't used at all (to my knowledge).

There are mods written in Groovy too, there's a language provider and mods.groovy for declaring mods.toml files for different loaders.

My stance in this issue is that people that care enough to have a Kotlin buildscript know enough to port it themselves. A modder that is just starting out should not need to learn how to write kotlin code (and understand its quirks and differences that are more significant than Java vs Groovy - i.e. delegation, which is something I often see people confused about, or providing class types using the <> syntax between function names and the parenthesis).

Eclipse Buildship added Kotlin DSL support late 2023.

*as an experimental feature, not available on Windows (or not at the time of writing the blog post), see eclipse/buildship#222 (comment)
For that matter, Eclipse will treat your buildscript as plain text, and Groovy is more forgiving to write than Kotlin, which is much more explicit (as it's a strongly typed language).

[thiakil]

Groovy suffers from the same problem,

uhh, no? It has basic syntax highlighting instead of everything being red

but this shoudldn't be a concern as the MDK is designed to always load as-is with no errors

designed to doesn't mean it always will

[lukebemish]

See https://discord.com/channels/313125603924639766/801175194298744902/1247764605556490301 for the sort of cases that would make me hesitant to see the MDK moved to the kotlin DSL -- there's still far too many cases that pop up that work perfectly fine with the groovy DSL that require the use of ugly, unintuitive, and undiscoverable configure<some.silliness.you.have.to.Import> { ... } blocks in the kotlin DSL. This may improve in the future in some cases, but in other cases can never be avoided due to kotlin's static typing -- and thus its inability to detect extensions added on objects that don't exist at plugin eval time when generating typesafe accessors, and there are plenty of such objects; as noted in the linked discussion, the many neogradle runs are not created at plugin apply time, and so won't have any extensions they might hold, like the devLogin block, detected. This is a limitation of the kotlin DSL that just cannot ever be fixed.

Furthermore, the val whatever: ... by ... syntax, and plenty of kotlin's other quirks, are very different from the java-like syntax groovy uses; we shouldn't needlessly confuse modders when gradle is already confusing enough.