I have been using Gradle now for almost 3 years and I can't be happier. The support is great, they roll out new features at a regular pace, it's fast and incremental build WORKS.
If you work in Java and you are still stuck with Maven, please, take a look at Gradle.
or ivy? i really haven't spent a lot of time toying with the various build systems. i tend to use ant until manual dependency management becomes ... unmanageable, then maven because i've apparently been brainwashed (i.e. i heard that they use maven at a lot of not-so-bad companies like thoughtworks).
after the article, i do like the suggestion of ivy+buck, neither of which i'd paid attention to before below the clamor of gradle trampling upon maven. before starting considerations along the lines "this software does not do X" or "it does X wrong," what about asking "what's a reasonable task for a single tool?" or more specifically,
"do we really want dependency management and builds handled by the same program?" my impulse is always to go for things that are as modular as possible, but perhaps the reflex response of "no" isn't correct for some reason obscured by lack of experience with the particular problem domain.
Gradle is a very powerful engine: we use it not only to build Java/Scala/Groovy code but also to drive our continuous integration/deployment cycle.
Again, it obviously depends on your requirements, but if you have to deal with large and complex projects, with lots of submodules to build, do consider Gradle.
A reliable, flexible and built on sane principles build system is required when dealing with large enterprisey projects.
How do you deal with versioned dependencies with Makefiles?
I'm not sure I'd call those things Rube Goldberg, it's just about depending on small libraries and having a reproducible build if it gets checked out on a CI machine and run.
As always, all about choosing the right tool for the job. If you can solve it cleanly with something simpler then you probably should. Something like Maven should only be used if you're really sure you actually need it, because otherwise it'll be a pain in the arse.
Having said that, splitting up "building" and "dependency management" can make things much simpler. Pip (python dependency manager) is incredibly simple, with the same kind of interface as apt, and if you've got a file with a list of dependencies you just tell it to install all of those. Then you can use whatever you want for the build process itself.
that's all over the java ecosystem, though, not just build tools: android and (i think?) spring both use several types of xml files to build. not saying it's not whacky, but it's def. prevalent.
I'd heard about that...as a non-Gradle Ivy user, when they started this, I asked two of their devs if they were going to basically write an "Ivy v2", submit their improvements/patches back to Ivy, etc.
Their response was, paraphrased, "absolutely not, we're building our own thing that is way more awesome and are not interesting in sharing". Which I found disappointing.
I know a clean break is easier, and that the Ivy codebase likely needs it, but Ivy could really have used their focus, and I think it would have benefited the wider Java ecosystem (as many non-Maven builds use Ivy to talk to Maven repos) instead of just Gradle itself.
http://www.thoughtworks.com/radar
In the Tools category, Gradle is "Adobt", while Maven is on "Hold". You can read the full report but I'll exert the relevant section:
"Language-based build tools like Gradle and Rake continue to offer finer-grained abstractions and more flexibility long term than XML and plug-in based tools like Ant and Maven. This allows them to grow gracefully as projects become more complex."
They had a more elaborate explanation in previous editions.
Having said this, I am also an Ant guy for simple projects. Too many scars from an Ant -> Maven migration. All pom.xml files ended up more complex than the original build.xml files, as Maven did not have proper support for the way the build was working before.
Why Everyone (Eventually) Hates (or Leaves) Maven : http://nealford.com/memeagora/2013/01/22/why_everyone_eventu...
I hated Maven until I tried the alternatives.
Please, explain incomprehensible (or show an example)
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.
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.
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.
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.
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.
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.