Hacker News Reader

Comment by SOLAR_FIELDS | Hacker News Reader

Adding onto the things that other people said: Gradle is an extremely powerful build tool. It has three tiered caching (project wide, machine wide, remote, with fallbacks), complex DAG resolution, and in general is just really good at building jvm stuff. It can handle nearly every weird way that you could possibly dream of to structure your project. It’s generally not super buggy. It’s generally pretty fast if you know what you are doing. There are years and years of optimizations built into it. It is the tool to build enterprise jvm code. If you go to a jvm shop at an adult company that isn’t stuck in 2006, they are using Gradle.

The downside is that it is insanely complex, and nearly impenetrable for newbies. It’s also for the same reason pretty Perl-like (a “write-only” language)

View on HN

I would also add that there isn’t too many players in its category of general build tools. Like, sure, you can have a go-specific build tool that is more ergonomic, but it chokes the instant you add a c dependency.

I guess there is only bazel and gradle that are on this level of capability, being able to compile polyglot code bases. Probably also cmake, but compared to that, gradle looks as if it was designed by God itself, even though it severely lacks in ergonomics.

Yeah, I’ll also add is that while Gradle is technically a generic build tool, in practice the ecosystem realistically only makes sense to use for JVM code. All of the JS, Docker, Python, other plugins have significant issues due to only being supported/maintained by a few people. As well as Gradle giving a lot of JVM based caching for tasks set up as part of vanilla Gradle, that aren’t set up in these other ecosystems.

I would argue Buildkit is also trying to be this kind of tool but is significantly less mature.

I strongly disagree. Gradle is extremely buggy where it matters the most. For instance, if I cancel a build part-way through and then run it again, gradle assumes that the in-progress JavaCompile task is completed, and proceeds to generate a Jar file containing resources but no classes. To fix this, I am forced to make useless changes, or clear my entire user-level gradle cache.

Doesn’t clean build (or the flag to build the incremental cache again by force) solve this?

Running "clean build" should do the trick though, it will delete the ./build directory. Or do you mean the local maven repo?

Neither. The corrupted cache is in the user-level gradle cache directory, which is untouched by `gradle clean`.

No, running `gradle clean` only cleans the project-level cache as far as I can tell. It leaves the user-level cache untouched (as far as the issue is concerned). Not sure about that flag you mention though. I'll have to look into that.

Reply on news.ycombinator.com