[eshvk]

> While I personally prefer Gradle’s nice DSL and the ability to use imperative code for non-common build operations, I can understand the preference for the fully declarative Maven, even if it requires lots of plugins. The modern Java developer, then, might prefer Maven to Gradle.

I find Maven's abstractions surprisingly hard to understand. It is a major part of my annoyance with Java as a dev setup. I miss Make/Ant. Not sure if Gradle will be a good replacement or not but would be curious to try.

[zmmmmm]

I find all of them hard to work with, because they are all aiming for the modern day "zero configuration" nirvana that Ruby on Rails achieved, and thus enormous amounts of implicit knowledge is required to understand them.

Part of the problem is that the initial steps are so easy that you're actually never forced to learn the mechanics of what is happening. Hence you get away with a lot until you need to do something there isn't a magic command for. This is also why you see blithe statements that you "don't need to know Groovy to use Gradle", etc. However these are only said after the fact when you've learned Gradle, understood enough Groovy to intuit what it's doing and then retrospectively realised there is a theoretical path from ignorance to enlightenment that didn't involve learning Groovy.

What you would probably like is Gant, which is Ant entirely converted to Groovy. It's missing all the higher level project stuff from Maven / Gradle, but it works a treat when you just want the simplest possible thing that could work.

[eshvk]

> I find all of them hard to work with, because they are all aiming for the modern day "zero configuration" nirvana that Ruby on Rails achieved, and thus enormous amounts of implicit knowledge is required to understand them.

> ... realised there is a theoretical path from ignorance to enlightenment that didn't involve learning Groovy.

Yes! Learning is so non-linear that sure there are in theory fine lines that minimize the amount of new stuff to learn. Yet, it never is that simple. Bad design, indeed.

> What you would probably like is Gant, which is Ant entirely converted to Groovy. It's missing all the higher level project stuff from Maven / Gradle, but it works a treat when you just want the simplest possible thing that could work.

I will check it out; thank you!

[thejdude]

At least with Maven you have a standardized build process in every project. Checkout the code and be productive right away. It structures dependencies and project layout.

Currently I'm in a large enterprise project where the build department decided it was a good idea to reimplement a whole complex build in gradle (basically all that maven does by default). It didn't help that they didn't realize Gradle uses Maven conventions by default, ignored that and ran their own dependency system. The build is REALLY slow and really complex and nobody has any idea exactly what it does.

In ant having a non-standard project layout was ok, but then at least the build was FAST and didn't take half a minute just to START the build system.

I'm not yet sure if gradle actually IS better if you use it right, or if it's just a very very slow solution to a problem you shouldn't have it the first place if you do it right with something like maven.

[krschultz]

I really enjoy Gradle. I have done significant work with Ant, Maven, and a host of tool chains in the C/C++ world. Gradle seems to have the cleanest DSL. Not every single thing under the sun is supported (Maven seems to be the most comprehensive tool I have used), but Gradle is nice to work with.

[Groxx]

I've been struggling to find out what's even available in Gradle. How does one debug it, or print available methods, or really anything?

My woes are mostly around Android's gradle integration, which appears poorly documented at best. There are tons of magic commands that appear out of nowhere and with no explanation beyond "use this.". And Gradle's massive guide covers things that barely see the light after being seemingly wrapped in several layers by Android's plugin.

I want to give it a real try, but the Android projects I deal with are reasonably complex, would use code generation (`scopes.PROVIDED.plus += configurations.provided }`? wtf does that even do and how in the world would I have discovered I could use it?), and need multiple products. I would have to know what and why before considering switching over for real, but there seem to be some huge walls preventing me from finding out.

[lmm]

What abstractions? You have a project which has a name and some other metadata and it has a bunch of dependencies. If your build does something weird then it also has plugins, but you should try to avoid those as much as possible. I guess profiles could be confusing, but again, try to avoid them. Maven is the simplest build tool I've used, in any language.

[mike_hearn]

Maven has a lot of jargon. I also found it confusing when I started. POMS, artifacts, plugins, reactors etc ... heck I still find Maven confusing and unintuitive sometimes. Their docs are awful: typical failure mode for software that's in love with the idea of plugins.

[eshvk]

Exactly. With Make, I can delve down into the bash code easily and figure out what is happening. With Maven, there is enough overhead that I have to resort to cargo-cult googling.