- slow resolution (could be really really really slow)
    - transitive dependencies could be a mess since it could actually will mostly give you a evicition but it's hard to actually resolve that.
    - however if you have two plugins a evicition is not printed, so you will actually get a funny stack trace if you actually use a library that resolve something via reflections. (i.e. closure compiler)
    - sbt is slow
    - sbt has some wierd operators.
    - has problem with dynamic ranged versions
    - scoped settings are cool, but could be wierd to understand, especially for new people
    - sbt-web which tries to use npm which it packages as webjars which actually is a total mess since you actually run into the great world of npm packaging and try to force it into a completly different format.

What you're asking for is Turing-complete XML.

History has shown that this is usually a mistake.

https://github.com/jruby/jruby/blob/8e29ae1302e7aa989b8808f7...

[1] -- https://github.com/takari/polyglot-maven

(And because its "config" files are arbitrary turing-complete code, its IDE integration is never going to be as good as Maven's)

And as in all things if your code gets too complicated you need to refactor, extract logic into methods/classes, etc.

I do have a problem with Gradle which is that it is almost entirely magical unless you are a pretty advanced Groovy programmer to understand how it is doing what it is doing. I have never felt more disoriented than when trying to learn how to customise a simple aspect of my build and having people post snippets that work but seem completely disconnected from anything else in the build process.

And maybe this is making a virtue of necessity, but I find the overhead of creating a plugin stops people from putting random "different compiler arguments on a Wednesday" conditionals in every build, which is all too common if you give them immediate access to a turing-complete language.

Your criticism applies equally to non-build code. Don't approve PRs for bad/inscrutable code.

In gradle you can build plugins just like maven. But a simple 'if then' doesn't require all the heavy lifting of a plugin.

But code is where logic goes. People expect logic there. It's the same objection as to logic/conditionals/looping in web templates, or routing config files, or persistence object mappers. If it's logic, it belongs in code!

    - I dislike the DSL // not a really useful criticism I know.
    - Some things needs Groovy which isn't a mainstream language
    - Had Bad support for Scala, which I use heavily mostly resolved since 2.2 and thanks to linkedin newer version even have twirl + playframework support.
    - sometimes the syntax file of the DSL couldn't be highlighted in eclipse / intellij
    - Bigger build files could be really slow (mostly resolved in newer versions)

Originally on Gradle.org's website, they wrote they'd encourage anyone who wanted to enable Gradle to allow another scripting language for writing build files, and that they'd help them with bundling it. But since Gradle 2, it looks like too much of Gradle's own source and plugin code is written in Groovy for that to still be feasible. Gradleware also employed one of the former developers who used to work on Groovy when they were retrenched by VMWare a year ago, and I suspect he'd actually sabotage any outside attempt to make Gradle polyglot, like, say, Vert.x is. So it looks like you're stuck with Groovy if you want to use Gradle. With the good comes the bad, as they say!

- It is the slowest of all JVM build tools available.

- Hard to know what DSL should look like in each version.

- Seems like the only thing keeping Groovy afloat

Gradle's biggest problem is that it's too flexible.

  > I still missed something on top of Executors and CompletionStage.

http://beust.com/kobalt/home/index.html

Well yes they could be - but this isnt a project to build a general purpose build tool so this is not really relevant