Could you please make the settings.gradle.kts and ...

# amper

[Waldemar Kornewald]

Could you please make the settings.gradle.kts and gradlew etc. optional, so you can really start with just a module.yaml and an src folder? This might require auto-adjusting the RAM limits, so we wouldn’t even need a gradle.properties file. 🙂

[Anton Prokhorov]

Thanks for suggestion, we are collecting requests to understand where demand is

[Anton Prokhorov]

btw, what you propose to do with gradle wrapper?
and why would you like to get rid of these files?

[Waldemar Kornewald]

I’d find it cleaner to get rid of the wrapper and everything and instead have a globally installed cli tool. It would be great to get what Go, Rust and Flutter have (links point to examples). They only need a `go.mod`/`Cargo.toml`/`pubspec.yaml`.

Same with Amper, just put a module.yaml file in your repo and you’re done.

Compare that to Gradle: My usual flow is to open some pre-existing project for copying those files. Then I select all the necessary files (gradle folder, gradlew, gradle.bat, gradle.properties, build.gradle, settings.gradle.kts). Then I copy those to my new repo. Most of the time I don’t get all files right on the first try, so I have to repeat. Oh and we also have a real-gradlew because that seemed to be the only way to have slightly different resource limits for the CI. Then I’m sometimes paranoid and check whether gradlew is really marked as executable. Then I remember I might better check if I’m using the latest Gradle version, so I check gradle-wrapper.properties. Sometimes I might have to re-generate the gradlew files because of an update. Then I also double-check again if gradlew is marked as executable. And then I’m paranoid again and check if really using the -all variant of Gradle in gradle-wrapper.properties. And finally I might decide to also update Gradle on all the other repos... This is insane for someone as paranoid as me. It’s also really bad as a first-time user experience.

I think it’s already difficult enough to copy a .editorconfig, .gitignore and module.yaml to get started with a new project. 😄

[Waldemar Kornewald]

Oh and the reason why I copy manually instead of using the IDE is that the IDE always generates a non-scalable Gradle setup that I’d have to manually clean up. I want our own conventions setup and the IDE shouldn’t get in the way (this can also be annoying when the IDE says Kotlin isn’t configured and when you try to configure it will go through all build.gradle files and manipulate them and break them all and then you have to be careful when reverting).

With a module.yaml the IDE might provide a much nicer experience with a good default template that doesn’t need any custom set of scripts which live in our gradle folder currently. Several times we tried buildSrc, as suggested by the docs, but that works so bad it must be the road to hell… and the real solution is to create an actual Gradle plugin but then good luck learning how to do that when your schedule is full with other important tasks.

[Waldemar Kornewald]

Honestly, I have developed a little aversion against Gradle and just seeing these files in the repo makes me feel uneasy

[Waldemar Kornewald]

Gradle is not a build system. It’s a framework for building build systems. And that’s what everyone is doing. Madness.

[Amejonah 1200]

You can install Gradle too if it is what you want, the wrapper is for ppl who don't know how to install things or don't want to do it

[Waldemar Kornewald]

This doesn’t really scale because all our developers would then have to manually maintain that Gradle install and possibly maintain multiple versions because Gradle 8 isn’t compatible with Gradle 7. We’d always have to notify all developers that an update is needed. Developers would have to be onboarded and issues would have to be debugged. We already run into enough problems with setting up Cocoapods and npm and Nexus access… And that seems to be more a problem of Gradle because of the huge API surface and difficulty to stay backwards compatible for a very long time. In contrast, this problem is much smaller with Go/Rust/Flutter because of their simpler config format. And even if the format changes, one could either auto-detect the version based on the used attributes or add an explicit version identifier, but still keep support for older versions for a much longer time than Gradle can keep APIs stable or AGP can keep using old APIs.