I love good rant and this one sent me into paroxysms of delight!
About 9 out of 10 gradle build configurations that I have encountered fail to build something. That's surprising, and infuriating given that:
* Gradle is based on a portability layer, the JVM.
* Gradle competes against a portable and relatively reliable build system, Maven, and competes against make, which is non-portable due to its use of the system shell for arbitrary code. I would take Maven or make over Gradle any way of the week.
I have one other major beef with Gradle: every single Gradle-based project I have encountered on GitHub includes the Gradle JAR file. The author wants me to download and execute arbitrary Java code without even the option of inspecting it! To hell with that!
I had a breakthrough with Gradle recently: Gradle builds that fail on my Fedora laptop work just fine in an Ubuntu "toolbox" container. So much for portability!
Like the author of the article, I have devoted several (not as many) hours to understanding Gradle. It is largely incomprehensible, when encountered in the wild.
You do not need to use the gradle wrapper - you can use your own trusted version. Wrapper is there just for convenience. I understand your concerns, but it is not the only way and you are not forced to use it.
I actually have tried to use the trusted version that comes with the Fedora packages. It was quite a while ago so I don't remember exactly why that didn't work, but I think it had to do with Fedora packaging an older version of Gradle than the build configuration required.
So, nice thought. I guess I could work out what Ubuntu system the author used and set up a matching Ubuntu toolbox (container) with the right Gradle version. It's not really a win for Gradle if the developer's operating system has to be shipped with the build system.
Except that Gradle constantly releases new versions with breaking changes. You need to install your own trusted version for each version that you use, and know which one to use for each project.
I agree it is not easy to use correct local version, but that is why gradle wrapper is there. In case you do no trust it, you have workaround for it. For projects from company repository, this should not be issue. For random project from github, it may be worth to go the safe way.
Gradle: But at least we gave you a workaround. And this way we don't have to support backwards compatibility when we capriciously change our minds about something.
About 9 out of 10 gradle build configurations that I have encountered fail to build something. That's surprising, and infuriating given that:
* Gradle is based on a portability layer, the JVM.
* Gradle competes against a portable and relatively reliable build system, Maven, and competes against make, which is non-portable due to its use of the system shell for arbitrary code. I would take Maven or make over Gradle any way of the week.
I have one other major beef with Gradle: every single Gradle-based project I have encountered on GitHub includes the Gradle JAR file. The author wants me to download and execute arbitrary Java code without even the option of inspecting it! To hell with that!
I had a breakthrough with Gradle recently: Gradle builds that fail on my Fedora laptop work just fine in an Ubuntu "toolbox" container. So much for portability!
Like the author of the article, I have devoted several (not as many) hours to understanding Gradle. It is largely incomprehensible, when encountered in the wild.