Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

No, everyone is not moving to Gradle. Gradle is Ant in Groovy clothing. If you want incomprehensible build files ala Ant, choose Gradle. If you want standard build files and a rich ecosystem, choose Maven.

I hated Maven until I tried the alternatives.



> Gradle is Ant in Groovy clothing

Gradle's purpose is to muscle in on the consulting / conference market for Ant, just as Grails's purpose as wrapper around Spring and Hibernate was initially to muscle in on their consulting businesses. Now they've hooked in enough users, their bait and switch business strategy is now to screw them for as much money as they can.

So if you use Gradle now, you'll pay the cost later on after Gradleware is sold to some GE or VMWare or EDS or Oracle.


Yeah, no. Gradle is really nothing like Ant. A bad build script author can use it to write build scrips that look like Ant with curly brackets, but then you can write COBOL in any language. If you take the ten minutes to learn how Gradle actually works, then you don't end up with scripts that are like Ant.

Advocating Maven over Gradle is just a joke. I routinely do things in Gradle scripts that would require writing an whole new plugin to do in Maven.


Even for strict java builds, I've been using 'sbt' (the Scala Build Tool). It really is the successor to gradle, in many regards. Not sure you've tried it as one of your alternatives, but I'd implore you to give it a try.


I love SBT, but the learning curve is quite steep for the average developer.

Also the plugin ecosystem is not as wide as Gradle and SBT lacks a daemon, which makes builds 3X/4X faster in Gradle.

For Java builds (especially multi-modules builds) I still prefer Gradle.


> incomprehensible build files ala Ant

Please, explain incomprehensible (or show an example)


Ant user here. Ant is Turing-complete, which serves as an object lesson in "can" versus "should". I have actually had cause to program in Ant - because that was the right place for the complexity in question - and would characterise it as what COBOL would look like written as correctly-formed XML. Oh the verbosity!

To be fair, I'm doing things that are actually bad and wrong. (At which point ant-contrib is your last friend.) Ant does its actual job - makefiles for Java - pretty well once you know it. It's fine, y'know, probably pretty much complete.


Here's Netflix Exhibitor (which I wrote): https://github.com/Netflix/exhibitor - the developer who wrote the build scripts did an incredible job. I'm very impressed. However, I don't comprehend it. Note: this was previously in Maven and had exactly 3 POM files.


Thanks for the link.

To my eyes, the build scripts are pretty clear. I like the way the scripts are nicely organized using 'apply'. Maybe the only script that may look complex to someone starting with gradle is 'convention.gradle', but again, nothing impossibly hard to grasp for a developer.


No at all clear to me. You think https://github.com/Netflix/exhibitor/blob/master/gradle/rele... is clear? What about https://github.com/Netflix/exhibitor/blob/master/gradle/lice...? What is "ext.year"? I don't want to learn and understand an entirely new language for my build.

I am not able to maintain these build scripts. This is the problem with DSLs in general. Maven isn't great, but its strength is standardization. I can look at any Maven pom and know what it does and make changes to it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: