Hacker News Reader

Comment by smrtinsert | Hacker News Reader

There are no winners in the build war despite the overwhelming online support for Gradle. Personally I'm not a fan of it. I find it on the slow side even compared to maven. I'd rather have declarative builds like Ant but therefore support better tooling than super freeform tools like Gradle that force you to drop into a language with about as much type safety as Javascript. Multi-project builds are also annoying, as Gradle has to parse and validate all the connected projects before proceeding with one single task on the build you're invoking due to its design. Very annoying stuff.

View on HN

The performance problems are definitely the most annoying part of using Gradle. The Gradle daemon helped a little but tended to break other things and Gradle was still pretty slow.

If you are looking for something faster and more declarative, you may want to check out SBT[0]. It is way faster than any of the other JVM build tools. Also, in the future[1] it should have much better tooling support than anything else on the JVM.

[0] - http://www.scala-sbt.org/ [1] - https://github.com/sbt/sbt/wiki/Client-server-split

SBT has a terrible habit of breaking backwards compatibility, which has put me off it.

I've never had to change anything between upgrades (aside from changing deprecated stuff). Are you referring to the jump between from 0.7 to 0.10 a few years ago or have you had more recent issues?

Yeah, I just went and had a look at the project in question and I'm being unfair to SBT, it was a plugin I use to package WARs that changed underneath me. The plugin was quite closely coupled to the version of SBT, but the latest variant of it (once I found out about the migration to a different artefact) seems good.

Right now, SBT + IDEA is a bit of a pain because they share the same target folder and IDEA sometimes overwrites/deletes .class files that your application (started via sbt run) hasn't loaded yet. Usually that leads to a few ClassDefNotFound errors and such. Hopefully that'll go away once we have a single SBT instance.

My two wishes for SBT would be: 1) A monadic style for .scala build files. It would make dealing with the immutable bits of project definitions so much more pleasant and we could avoid the weird semi-Scala syntax of .sbt files. And 2) A bottom-up approach similar to Pants. My team frequently end up getting a lot more project interdependencies than we bargain for simply because it's too easy to induce transitive dependencies.

Would you mind elaborating on what you mean by a monadic style for .scala build files?

PS - You may already know this, but you can change IntelliJ's compile output directory [0].

[0] - http://www.jetbrains.com/idea/webhelp/configuring-module-com...

Thank you, I haven't actually tried that. I really live the "I just want my IDE to work" philosophy (out of laziness), so I try to avoid configuration if I can. :)

About monadic style: I realize that it's a hard sell, but it's basically about leveraging for comprehensions (aka. do-notation) to specify your build. Shake is an example of this, although probably not particularly suited to building Scala code.

Shake?

Sorry, should've linked[1]. There's also a further link from there to a paper for your reading pleasure :).

[1] http://hackage.haskell.org/package/shake

Thanks!

> I'd rather have declarative builds like Ant

Is that a typo? I'd say Ant is the opposite of declarative.

It's interesting. Ant is a somewhat constrained imperative language. Gradle is a highly constrained declarative language built on top of, and with an escape hatch to, a completely unconstrained imperative language.

If you stay within the bounds of that the Gradle DSL can do, rather than throwing Groovy around (which is possible - i write a lot of Gradle, and very rarely write raw Groovy), then Gradle is rather nice and easy to reason about. But if you don't, well, you're going to have a bad time.

I've definitely found gradle to be faster than maven, particularly using the daemon, and even more so considering the extensive support for understanding when a task is up-to-date. I haven't run a clean task in gradle in several months, but in maven it seemed to be a crapshoot if the clean was required or not. That saves a lot of time.

Reply on news.ycombinator.com