4 ms·

This is why folks should stick with Maven and live a happy, generally drama-free life. As a Gradle veteran, I've written in detail about this previously: http

This is why folks should stick with Maven and live a happy, generally drama-free life. As a Gradle veteran, I've written in detail about this previously: https://news.ycombinator.com/item?id=38875936 https://news.ycombinator.com/item?id=38875936 TL;DR: Gradle is too powerful (which is fun and seems valuable at first!) with too many footguns. Combine this with the mandatory update migrations and you're literally signing up for future pain compared to using a lower change-rate build tool like Maven. Do you really need to run arbitrary commands to build your app? If so, take a deep gaze in the mirror and reflect on what you're doing with your life.

kaba0 2y ago
With all due respect, that’s a blatant misunderstanding of gradle (though gradle’s documentation not being clear enough, giving to the spread of this misunderstanding is a fair criticism). Gradle is not too powerful, it builds a build graph based on the .gradle file, and the building itself happens imperatively — but the actual execution is static, based on that fixed build graph. This configuration is cached and subsequent executions will all refer to this static graph to know what requires rebuilding. This is the minimum required complexity/generality for a build system that is not “hardcoded” for a given task (e.g. to a degree maven, but cargo, go’s build tool etc all can only compile their respective languages on their own. “Plugins” can let them do more, but at that point plugins have to re-develop all the functionality of a build system - caching and parallelization), and as I mentioned there really are only a handful of tools capable of that. As for valid criticisms of gradle - it’s API historically experiencing constant breakages, used to be dependent on JDK version (and lagged behind for a long time due to Groovy), which is more or less fixed now with toolchains, and the model not being clear enough for people not wanting to dive deep. E.g. I can count on a single hand how many people knows that doFirst/doLast should be used for the actual task itself, anything else will happen at the config build time which is not what you want.
- drzaiusx11 2y ago
  Saying Gradle is the minimum possible for a build tool because it generates a dependency graph is a bit of a stretch. Gradle is essentially a custom groovy/kotlin build script dsl in addition to a dependency manager. I just want the latter; leave the former to existing tools. Maven and plug-ins can do the same without learning a new (and brittle) dsl. Worst case in maven you have to write your own plugin, but then you just use their documented plug-in API (import org.apache.maven.plugin) like any other JVM project.
pjmlp 2y ago
Gradle was created by folks that didn't learn the Ant lesson, and only matters thanks to Android. Had it not been for Android replacing Ant with Gradle, and most folks wouldn't even remember Gradle.

kaba0 2y ago

With all due respect, that’s a blatant misunderstanding of gradle (though gradle’s documentation not being clear enough, giving to the spread of this misunderstanding is a fair criticism). Gradle is not too powerful, it builds a build graph based on the .gradle file, and the building itself happens imperatively — but the actual execution is static, based on that fixed build graph. This configuration is cached and subsequent executions will all refer to this static graph to know what requires rebuilding. This is the minimum required complexity/generality for a build system that is not “hardcoded” for a given task (e.g. to a degree maven, but cargo, go’s build tool etc all can only compile their respective languages on their own. “Plugins” can let them do more, but at that point plugins have to re-develop all the functionality of a build system - caching and parallelization), and as I mentioned there really are only a handful of tools capable of that. As for valid criticisms of gradle - it’s API historically experiencing constant breakages, used to be dependent on JDK version (and lagged behind for a long time due to Groovy), which is more or less fixed now with toolchains, and the model not being clear enough for people not wanting to dive deep. E.g. I can count on a single hand how many people knows that doFirst/doLast should be used for the actual task itself, anything else will happen at the config build time which is not what you want.

drzaiusx11 2y ago
Saying Gradle is the minimum possible for a build tool because it generates a dependency graph is a bit of a stretch. Gradle is essentially a custom groovy/kotlin build script dsl in addition to a dependency manager. I just want the latter; leave the former to existing tools. Maven and plug-ins can do the same without learning a new (and brittle) dsl. Worst case in maven you have to write your own plugin, but then you just use their documented plug-in API (import org.apache.maven.plugin) like any other JVM project.

pjmlp 2y ago

Gradle was created by folks that didn't learn the Ant lesson, and only matters thanks to Android. Had it not been for Android replacing Ant with Gradle, and most folks wouldn't even remember Gradle.