gradle variables incompatible with fabricmc.net/develop/ variables about example-mod

[SmushyTaco]

Understood, being able to have snake case in the gradle.properties and camel case in the build.gradle.kts would be ideal. I'll look into solutions for this in the future for this as I don't want to compromise the actual build file for this. Thanks for bringing this up to me!

[SmushyTaco]

Might have found a solution, going to test it now and if all goes well this issue will be resolved 😄

[SmushyTaco]

Issue has been resolved! Thanks for bringing this to my attention!

[rapus95]

thanks for putting effort into solving this! ☺️

[EnergoStalin]

Upvote issue. Please consider change naming

[SmushyTaco]

I'm confused, do you want it changed because of personal preference or is this actually causing issues? If it's causing issues go more in depth on the issue please.

I've decided to use camel case because the build files are in Kotlin and that's the naming convention Kotlin uses. If you explain your reasoning further I'll gladly change it.

[rapus95]

I recently started to dive into building a Minecraft mod and everything is new to me. I generally know programming, but not kotlin. So I went step by step through https://fabricmc.net/wiki/tutorial:setup where it pointed me to this repo for a kotlin mod and said to update the versions for being conform to https://fabricmc.net/develop/ . There's a code area which looks like it has the right format for the gradle file. So I just copied and pasted the text without even noticing that the style changed from camel to snake and I also wasn't sure if the gradle auto migration worked for the kotlin version too. Then it errored and it took me almost 20 mins to understand that copying right from the fabric page corrupted my program. So my suggestion would be to either go conform with the java version or request an integration of kotlin specific instructions on the /develop page.

[rapus95]

I guess the easiest solution would be an indirection in the build file which looks for both tags in the .properties and then moves it to a new variable which is used everywhere.
just out of curiosity, java is a camel case language too, isn't it? How do they solve not compromising their build file?

btw on a side note, is there any way to replace all occurrences of mod_id (which is also snake case btw) and author in all places in a language agnostic way?

[SmushyTaco]

I guess the easiest solution would be an indirection in the build file which looks for both tags in the .properties and then moves it to a new variable which is used everywhere.

just out of curiosity, java is a camel case language too, isn't it? How do they solve not compromising their build file?

btw on a side note, is there any way to replace all occurrences of mod_id (which is also snake case btw) and author in all places in a language agnostic way?

Well build files by default are actually in Groovy not Java which is a weakly typed interpreted language and they use snake_case there. Kotlin added build file support and I chose to use Kotlin for this mod template because of the IDE support that comes with using a compiled language (like Kotlin) for build files rather than an interpreted language (like Groovy). It just made more sense to me.