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. 🙂

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

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. 😄

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

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.