After doing couple of Android projects with Gradle I've felt like Maven is a godsend.

It might require writing some XML to declare what your project does, but at least it WORKS and at least it does not waste my time by forcing me to write code to include pieces of projects and properly process project (e.g. including native code, Robolectric testing, renderscript and some other things).

Also any compilation inside IDE's was orders of magnitude faster with Mvn than with Gradle... all in all setting up all the components with gradle took about 2-3x as much time. Mostly it seems like someone decided that because now you have code instead of XML for build configuration, they'll just skip most of the plugin design and force you to roll half of the build process on your own.

Right now (at least for Android), Gradle is a colossal waste of time due to lacking features, extremely slow execution and myriad of bugs which will eat away productive time on project.

> Right now (at least for Android), Gradle is a colossal waste of time due to lacking features, extremely slow execution and myriad of bugs which will eat away productive time on project

Are the sparse features, slow executes, and bugginess due to Gradle or due to the scripting language it uses? www.gradle.org/overview says they will happily support any community effort to create additional build script engines for Gradle. The Gradle developers had better do it themselves because after the Groovy++ fiasco, noone's going to put work into building something related to the Groovy ecosystem when it's likely to be skuttled and/or stolen later on.

From the usual JUG discussion themes I also get the impression, if it wasn't for Gradle, the Groovy interest would be much lower nowadays.

There was a Grails wave here in Germany, but now I seldom see anything related to it.

Yesterday's Who is hiring? (https://news.ycombinator.com/item?id=7679431) only had 1 mention of Groovy or Grails (and none of Gradle) out of over 400 comments. And many (most?) of the projects tagged Groovy on Github are triggered by a single Gradle build script for a project that uses some other language. These Gradle build scripts are often 30 lines long.

So I'm not sure how Groovy will fare in the future. Nothing seems to be taking its place, though, for testing and general manipulation of Java classes. Java and Scala are statically-compiled languages for building things, whereas dynamic Clojure seems to also be used for systems programming rather than scripting. I'm guessing Oracle will heavily promote Nashorn for scripting and JavaFX, but Javascript syntax doesn't seem quite as full-featured as Groovy for now.

I seldom used it.

Back in 2009 there was a big Grails wave here in Germany. Many JUGs had Groovy and Grails talks.

There was also some people trying to use Groovy with JSF. Myself I attended a session promoted by Sun hitting at possible official support after the JSF 2.0 release.

To the point we added support to it in our in-house JSF framework SDK, still JSF 1.x based.

Since late 2010 I have been doing .NET land mostly and now back on Java land, I hardly see any Groovy besides Gradle.

I think it's just mostly the fact that tools aren't complete: e.g. IDEs will parse Maven pom.xml and use internal builders to speed up compilation while when using Gradle you're always spawning the external builder.

Same goes with other things: we had to write Groovy code to handle build cases which Maven plugins handle by default. That's mostly an ecosystem issue.

for normal dependency management you shouldn't need to write code. I've never done any android dev, so I can't comment on that. declaring a dependency is literally like this:

dependencies { compile group: 'commons-collections', name: 'commons-collections', version: '3.2' testCompile group: 'junit', name: 'junit', version: '4.+' }

But I am not going to be the great gradle defender :) I have many complaints..... I would have much preferred that Rake became the default build system for java. Sadly that approach never took off....

Yeah, for normal dependencies that's true. But on Android you quickly get some additional things that have to be handled by the build system:

* Code generation from annotations (reflection on Android is slow, so doing code generation is way better) * Attaching native .so libraries in proper directories of APK (Maven plugin does that automatically, Gradle needed writing code for that to work) * Properly handling RenderScript backwards compatibility library (there was no Gradle support for that at all)

* Testing - Robolectric is still not supported which throws a wrench into whole Jenkins/TeamCity autotest stack and needs fiddling with emulators

> Maven also suffers from XML hell, but at least it has dependency management.

I don't find it that bad. The nice thing about it is how my IDE will auto complete almost everything and it should be possible to validate it without even using an IDE, as it has a schema. I agree with your complaints about Ant.

The thing I was hoping gradle would give me is the ability to write tests for my build. EG: I want to have more confidence that my maven filtering is working the way I want it to. But it sounds like gradle isn't built with that in mind.

Considering that groovy is dynamically typed, if my IDE doesn't auto complete (maybe it does) I think it's possible to make the argument that Maven is the least awful of the 3. At least the maven XML has a schema. I don't need yet another way to make a mistake in my build script (ie: typing issues).

> Java devs do many things manually that a Ruby/Python dev would be horrified at....

Such as?

w/ regards to gradle using groovy.... in gradle I can easily add in variables to my dependencies, I can write conditionals (if System Prop X then include dependency Y).

Basically anything you can do in code, you can do in gradle very easily.

Auto-complete does work in IntelliJ 13 - at least for groovy code type stuff. Nothing for the gradle DSL (that could be implemented of course).

> Java devs do many things manually that a Ruby/Python dev would be horrified at....

Jenkins config - almost every one does this by hand. Jenkins jobs weren't really even designed to be automated (ironic, eh), you have to build a full xml doc for each job rather than say apply a similar change across all jobs (add in a -D param across all jobs for example). I know this is a Jenkins specific issue, but this mentality is very common in java land.

Others: have every dev manually install a database for their environment (Chef/Puppet/Ansible solve this - and what are they written in? Ruby/Python)

No one would ever use java for any scripting type work, the JVM startup time is awful + the file/string libs are far less powerful/usable than ruby/python.

Of course a java dev can learn one of the scripting langs, but they typically don't.

this is just my experience, but note I've seen a lot of shops...

> I can write conditionals (if System Prop X then include dependency Y).

I stand corrected. That would be extremely useful. Maven is really awkard about these things. EG: "I want to run integration tests but not unit tests". Here's how: http://stackoverflow.com/questions/6612344/prevent-unit-test... Pretty lame.

A better solution is to use profiles.

Writing tests for your build script is an interesting idea. I wonder if this would be easy to do in something like SBT where the build definition is itself an SBT project.

Actually, Maven uses XML right - as configuration, not code. This is where Ant was terrible - you ended up writing imperative code with XML statements.

Declarative builds = intelligent tooling. Would json make it better? I hate editing json too. Personally I would go with toml but wait... that would look similar to something else...

Ant's real problem is that it never found a path towards next generation. Why isn't ivy included by default? I want something bigger and easier to use that isnt gradle or maven but is more along the lines of an Ant+ivy default. It should have a bootstrap script, it should understand default project directories... It should continue to be declarative, but it should have an xsd or similar descriptive format that can be used for tooling.

There is a future in the ant+ivy perspective that I don't see in other build tools.

that's absurd. 1) I can't embed code in XML. 2) Why should I use a format that takes 5x as much space to declare something as a more usable format?

Agreed. On top of which XML has no capacity for logic, barring an incredibly contrived construct.

What kinds of logic are you putting in your builds? That's a sign you are doing things wrong.

hmm I wonder why this got created? http://ant-contrib.sourceforge.net/tasks/tasks/

I wonder if anyone said this about HTML when javascript was introduced?

once a system starts getting complicated you inevitably need code.

two points:

* gradle builds can be completely declarative. you write code only if you need it

* builds also are often used for very specific automation. in ant, you end up having to write custom ant tasks. this is fairly painful compared to just creating new classes, tasks, or scripts directly in gradle.

I often find that "can be declarative" means that over the long term in a big project means "isn't declarative"

After all you can do functional programming in any language. Why do you need another.