breautek commented on PR #1678: URL: https://github.com/apache/cordova-android/pull/1678#issuecomment-2102557642
> Having an issue with `npm t` not able to download and use gradle wrapper. I think I know what you're running into. It's dumb but gradle cannot install the gradle wrapper if the project does a gradle version check (which the android gradle plugin does). In otherwords if AGP requires Gradle >= 8.7.0 it will prevent a lesser gradle version from using the gradle wrapper task to install a 8.7.0 wrapper. Using gradle's `--gradle-version` is hella lot easier than what we did before, which involved deleting the wrapper because even if you switched to the new version it won't use it if it already had a wrapper installed. The wrapper task manages all of that for us and is what Gradle [recommends](https://docs.gradle.org/current/userguide/gradle_wrapper.html#sec:upgrading_wrapper). They also recommend to check in the wrapper, which is also dumb imo (breaks the general rule of no "built" artefacts in the repo, cause it causes headaches during PR and merge times). So we either: 1. check in gradle wrapper into the repo, and exclusively use it always (e.g. remove all references of the `gradle` executable, which is only ever used to manage the wrapper). 2. Require users to require the appropriate system gradle version. Option 1 is following Gradle's recommendation but I think can run into issues that can be problematic. For example, what happens if the end user uses the preference to install a gradle wrapper less than the minimum required by AGP? Will it run and switch for it to fail later once it starts using the unsupported wrapper version? Once the wrapper is out of date, the only way to fix it is to use the appropriate system gradle at the proper version. Option 1 seems like a better approach and follows Gradle recommendations has some concerns. Option 2 seems like a much safer approach, just more annoying for end users and defeats the purpose of using the wrapper really. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
