5 ms·

And when gradle fails (which is frequent) your debugging abilities are extremely limited. For example, someone “donated” a gradle build script to an open sourc

And when gradle fails (which is frequent) your debugging abilities are extremely limited. For example, someone “donated” a gradle build script to an open source project I help maintain. It lasted less than 6 months before it began breaking, not because we changed stuff, but because gradle updates had changed how some things worked and a plug-in stopped working. Now “obviously” the answer is that we should have pegged the version of gradle required to use the script, but (a) I don’t even know if that’s possible (b) the donator definitely didn’t think to do that (c) who changes such things in such a production level tool during a stable release cycle? Now the gradle people certainly seem decent, in my interactions with them, but I think there is unfortunately a strong case of Stockholm Syndrome going on there.

pbourke 6y ago
> Now “obviously” the answer is that we should have pegged the version of gradle required to use the script My first step with either gradle or maven is to install the wrapper generator, which has this effect. After adding the wrapper you invoke it via ./gradlew or ./mvnw in the project directory. The version of gradle or maven is then pinned until manually updated. It’s not perfect - especially in terms of IDE support - but it’s crucial for keeping your CLI builds consistent across team members and in automation. gradle wrapper: https://docs.gradle.org/current/userguide/gradle_wrapper.html https://docs.gradle.org/current/userguide/gradle_wrapper.htm... maven wrapper: https://github.com/takari/maven-wrapper https://github.com/takari/maven-wrapper