Maven is declaritive. IMO it's the best of the Java build tools. Gradle is not declaritive, unless it's changed since the last time I looked at it.

Maven has problems. It's not perfect by any means. I would love to see it rewritten, get rid of the verbose XML which makes viewing dependencies hard and fix the craziness around generated code.

Honestly, I'm tempted to make a fork of Cargo for Java, it's nearly perfect. But this goes against my opinion that build tools should be in the same language as the code they build.

Generally speaking gradle plugins take a very declarative syntax. Yes, it's easy to write non-declarative builds in Gradle, but that's what is awesome about it. Start with fully declarative builds, then add in non-declarative tasks if/when you need them.

My experience generally mirrors what you state. I transitioned a fairly significant code base & complex deployment process from a mix of maven and ant to gradle. I found Gradle's 'opinionated but flexible' approach to strike a good balance. It's definitely more complex, at least in our build, simply because of the size and scope of our project which has a wide variety of inter-dependencies which makes for a very complex task graph to build. But, the parallelism results in a far faster build/deploy cycle which is a worthy tradeoff.

We initially planned on going full maven, but its strict lifecycle and plugin system was simply too rigid. Beyond that, XML makes for some verbose configuration for even simple things.

We ended up developing our own Gradle plugins in static groovy and java, but it's very easy to do small bits/tests based on scripts and migrate functionality into specific-purpose plugins. Using Gradle was especially fortuitous when it came time to implement new areas of the product that relied on npm/node and webpack for front-end resource assembly.

Gradle hasn't been without its own minor growing pains (early lack of tooling support, rapid version changes), and it's certainly possible to create a big complex mess if you script everything ala ant -- but it's also possible to create very nicely defined DSLs and build systems that are expressive in use. Our onboarding got significantly easier in switching to gradle from maven+ant, and teams can now easily make minor tweaks for their build needs without having to learn maven's plugin architecture.

Builds, just like anything else, benefit from some best practices. I have no issue with Maven, but I won't start a new project with it.

Everything you said matches my experiences - the complexity has to be watched closely, but otherwise it's a huge boon.

I tend to agree. Gradle can be nice if you have a talented team, but in the hand of mediocre developers, its opening the box of pandora. I have seen build files you people wouldn't believe. And unfortunately, all that code will not be lost in time like tears in rain.

> Honestly, I'm tempted to make a fork of Cargo for Java, it's nearly perfect. But this goes against my opinion that build tools should be in the same language as the code they build.

The problem with that is that it doesn't work with slow / compiled languages. That's the worse thing about Maven (tied with the insane unnecessary complexity of the plugin architecture). The dev cycle for trying out a new plugin is atrocious. Compare that to editing a local copy of a Python, Ruby, or Groovy script.

I have spent one year taking part in a multi-team project to fix a build system, because everyone made their own little changes in Ant.

A chaos in a three site distributed system, with around 300 developers at its peak.

In this regard, Gradle is even worse than Ant in what concerns keeping a build infrastructure clean.

Oddly enough, my experience was quite opposite of yours, but it sounds like the scope of your system might be a little larger than ours.

The key to cleanliness (from my perspective) was to create versioned plugins for any build functionality that was required in more than one subproject. This simple rule prevents spaghetti task dependencies and maintains sanity for everyone. It gives us the best of both worlds -- a little bit of flexibility when needed for one-offs, but then a well defined DSL via plugins for anything that is done more frequently.

Gradle since version 3.0 provides Kotlin as well as Apache Groovy for writing build scripts.

Because I happen to like XML and Grandle is painful slow, requires tricks like a background daemon to cache build related information.

Also Maven is a project format in NetBeans. Just need to open it and its goals are mapped to IDE actions.

Maven in general is widely workable in almost any of the major Java IDE's out there, even with all the work Jetbrains has put into Gradle support it's still not up to par with what they've done for Maven (and considering how hard it is to introspect Gradle builds it may never be).

I feel like most people just hate Maven because of XML, if that's your problem then just use YAML (you can do that now). The other group seems to dislike that everything in Maven is done with plugins; I can understand this, there's no easy escape-hatch to do something no-declarative, but writing a Mojo isn't that much harder than putting some random task in your Gradle build.

> I feel like most people just hate Maven because of XML

I see this a lot. I definitely don't want to go back to the days of J2EE/Hibernate XML hell, but there are places where XML isn't terrible, and Maven feels like one of them - it is easier to figure out context when in bigger files (as opposed to JSON and the like), and it is nice that you can get very easy/quick feedback about the structure of the document via XSD. But when I ask people why they hate Maven, they give some handy-wavy "but XML..." argument about it.

I understand some of the more valid knocks against Maven, and there has been a time or two where I've been frustrated with it, but most of the time I used it (and I used it over a period of 8 years or so), I've been happy with it. I know that tools like Gradle and SBT allow you to do more, but I've always come away frustrated when using those tools.

Things I love having in gradle:

* custom tasks AND up-to-date checks for them (for when you invariably need special tasks like custom generated code, filtering only some resources in a certain way, calling other build systems like grunt/gulp, etc)

* up-to-date checks in general

* better task exclusions

* better dependency version resolution abilities, including custom strategies

* groovy syntax

Things I think maven does better that matter to me:

* classifier handling (it is really frustrating gradle still has a lot of messed up handling of them)

* way less magic is possible in the buildscript - makes it easier to trace through

End result: I could never go back to maven, every single project I've worked on has desired custom tasks and maven just makes it painful every step of the way. The only thing I worry about in gradle is making things easy to understand so someone else can follow behind - can't use too much magic.

What's the opposition to simply writing a Maven plugin versus tossing a bunch of extra logic in your build configuration? I understand there's some extra ceremony around it (you have to write a new project, publish the plugin to a maven repo or install it in your local .m2) - but I find it's a much cleaner and reusable solution than having a bunch of custom tasks dangling around build scripts.

The custom tasks are never reusable - they are specific to that one build. If they ARE reusable they become gradle plugins, same as in maven.

Effort of banging out a custom task to make a tar in a particular way and get it published: gradle=a few lines of groovy, maven=a full plugin in java?

To be fair my maven experience is the lowest of all (between gradle/ant/make/maven), but I was being honest in that I would never want to go back to maven (or ant) - I get more things done faster in gradle.

What MrBuddyCasino mentioned about mediocre teams though, that is a real risk. I'd nominate one or two skilled people to create and maintain it, but be sure to crosstrain and use comments liberally. The initial learning curve on gradle can be brutal for complex projects.

I'm kind of surprised you found Gradle slow. I did a fair amount of testing when we evaluated Maven vs Gradle for redoing our build, and I found Gradle to be significantly faster, even when running without the Daemon. Maven did not seem to have true parallelism at the time, I wonder if that has changed? Gradles task graph, though more complex, seemed far faster due to its ability to run non-inter-dependent tasks concurrently.

Let me guess, you guys have 16GB and SSDs.

Who doesn't?

Everyone that usually has corporate IT issued laptops.

NetBeans' Gradle support is excellent (though not as good as the Maven suppot), and surpasses the Gradle support in any other IDE.