Maven also suffers from XML hell, but at least it has dependency management.
I've used gradle extensively and it is quite difficult to figure out what is going on. Using a debugger would be nice, but it simply doesn't work. Gradle is terribly slow on a big project, the update checks are the main culprit. They should be done automatically in the background to alleviate this pain.
Since gradle is compiled rather than interpreted, calling code in the project being built is difficult and convoluted. For example, if I want to call a DBUtil.cleanDB() method in my java code I can't reference DBUtil in my gradle script as it hasn't been built yet and the Gradle script won't compile. If gradle was interpreted this problem wouldn't exist....
I find the DSL unintuitive and the inability to specify the order of tasks execution is always a sore point.
On the positive, at least it's a language, not XML. I have never understood the java world's obsession with XML and forcing it in directions never intended. This XML obsession has led to java being a major laggard in automation tech. Java devs do many things manually that a Ruby/Python dev would be horrified at....
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.
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.
There was a Grails wave here in Germany, but now I seldom see anything related to it.
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.
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.
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.
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....
* 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
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?
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 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.
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.
IntelliJ makes this a breeze. I'm sorry you aren't using it, that must make life really hard :-(
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.
After all you can do functional programming in any language. Why do you need another.
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
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.
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...
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.
Is that a typo? I'd say Ant is the opposite of declarative.
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 don't know of any other project using it. We are always doing Maven or Ant.
If Gradle is the future I hope it gets improved, I gave up on Android Studio given its dependency on Gradle and how it drags my dual core with 8 GB to its knees when compiling.
That could be the slow, dynamically-typed Groovy in Gradle that's dragging your machine. Gradle needs to bundle another build language. Since the goal of statically-typed (and hence speedier) Kotlin is to make it easier to write IntelliJ IDEA [1], on which Android Studio is built, instead of using Java, the logical choice is Kotlin.
Gradle's developer says they'll happily support any community effort to create additional build script engines other than Groovy, but it isn't a priority for them right now [2]. Perhaps the Kotlin team need to kick off a Kotlin build engine for Gradle (though because one of the Kotlin developers was a victim of the Groovy++ fiasco, I'd understand if the Kotlin people are hesitant about having anything more to do with Groovy ecosystem software like Gradle).
[1] http://blog.lunatech.com/2011/08/24/scala-ceylon-kotlin-goal...
So far I have been using the Eclipse ADT/CDT for my hobby development, mainly with C++ (just graphics stuff).
Then I thought to try out Kotlin instead, but could not. It was worse than waiting for my NDK C++ builds to finish, with the whole computer at 100% CPU usage.
I ended up filing a ticket, like many other developers already did.
I also know that Netflix use Gradle for pretty much all their Java stuff.
When that stops happening I'll start thinking about Gradle.
The title did warn that it is an opinionated guide.
I think most projects that used Maven before Gradle don't have enough incentive to migrate. A lot of the new projects, however, start out with gradle: Vert.x, Crate.io, RxJava.
I'm a little skeptical of this. More like the developer in the future uses Gradle. Usually when I go to a project's home page, I see documentation on how to include the Maven dependency, not the Gradle dependency. It's pretty obvious how to convert one format to the other, but my point is I think most people are using Maven.