> Now I prefer to stick with Maven

yep. This is the conclusion i end up with as well.

There's three stages to maven (and generally, build systems too). First, you use a tool like maven, and find that it sucks, because it didn't do exactly what you wanted. Then, second is you find a new tool to do _exactly_ what you wanted, which is usually something similar to make or ant (and gradle, in this case). It works, and you think you've reached nirvana. Then, third stage is you find out how much maintenance, headaches and gotchas you hit after using that tool. You curse and finally, having had enough, you switch back to maven (or use maven for a different/next project).

Now every time i see a build too in java that's not maven, i sigh. But only people who have reached stage three above truly understand, and accept maven, and the rest are always itching to move to something that "works better".

Snap! You describe my experience exactly. Funny thing is I was originally on ant so I've moved before when I found a real improvement. Gradle wasn't any better than maven.

Exactly my path as well. Was on ant, ant got cumbersome to maintain especially in big projects. Maven came up, "oh let's try that"! "But it's so painfully restrictive!", tried Gradle, eventually noticed that it's the same gunk as ant, just looking less like "programming in XML". Then ended up diving deep enough into Maven to learn how to make it behave and do what I want it to do.

Nowadays, in the most extreme case I write a new Maven plugin. But in 99% of cases I can come up with a solution using existing stuff. It's not always the straightforward solution, but in the long term it's usually better to maintain than what I'd cooked up with an imperative system like Gradle.

Me too. From Ant to Maven long ago. In the beginning it involved still quite some work, making plugins, running Nexus. But since Spring Boot, Maven is for me just a copy/paste activity.

Gradle is weird. Like if you use it correctly, you can do some genuinely impressive things with it. I've got Marginalia's code base set up as a multi-modular build which has an average compile+test time (in use) of 4-5s (as opposed to several minutes for a clean build). That brings a lot of value.

That's what it can do, and it's honestly pretty neat.

Now using Gradle, on the other hand, is a serious pain in the ass for all the reasons you listed. Breaking changes every release, weird dependence on JVM versions despite Java being a very backward compatible language, error messages that make gcc's c++ errors in 2007 look like the model of clarity, it's way up there with the most frustrating software I'm aware of.

Strap me to a chair and slowly pull out my fingernails, you're never getting me to admit I know anything about Gradle in a professional setting. I don't want to be the Gradle guy anymore than I want to be the guy who knows how to fix your broken Jenkins pipelines.

It’s gratifying to read so many people come to the same conclusion about gradle in this thread. There was an article a long time ago that made the case that most all build tools conflate two basic things; dependency management and compilation. Wish I had a link; maybe someone here is familiar? It explained the situation well.

> you're never getting me to admit I know anything about Gradle in a professional setting. I don't want to be the Gradle guy anymore than I want to be the guy who knows how to fix your broken Jenkins pipelines.

I feel this.

A big part of the problem is just the instability of the API.

If it was more stable, it would be possible to use e.g. stackoverflow to build a base of solutions to common problems, a canonical way of doing things, but since gradle keeps shifting and changing with every other release, that really isn't possible.

You can search "how to do X Gradle" and come away with a dozen implementations. There often seems to be at least 3 different APIs to accomplish a simple task, one ancient that's deprecated but kept around for compatibility reasons, one "new' that the Gradle devs later decided was bad, and then the proper "new" one which doesn't have all the features that people needed.

I have to agree. The moment I laid eyes on Gradle, I knew the Java ecosystem was going to continue its decline by the community’s adopting it as the new defacto standard. I have never adopted Gradle and have only used maven in all my projects.

There is a point I want to make about the excessive complexity of projects funded by Enterprise support/training revenue models. However, I cannot do so because I have no good data to back up any claims I want make.

If someone has the data, please enlighten us.

> I knew the Java ecosystem was going to continue its decline

Has it?

I always felt that Gradle combined all the negatives of ant and maven in one convenient package.

Gradle's unconstrained and unstructured scripts are a major step downward compared to the predictable XML of Ant and Maven.

For example, I have a very standard "build.gradle" for a React Native app that, in about 60 lines,

  - defines debug, release etc. build variants
  - sets SDK versions (to values from elsewhere)
  - contains passwords in plain text (for Java key stores)
  - sets the name of the app
  - conditionally chooses arcane linking instructions
  - includes freshly downloaded stuff from node_modules

It's a classic instance of "they were so excited that they could, that they didn't stop to think whether they should".

That is a great way to put it.

The longer I'm in the industry, the more I hate build systems that use languages.

Build systems should be declarative rather than imperative. If you need complex stuff doing, it should be done outside of the build system. make was sufficient (subject to a few minor changes).

Rust - cargo.toml. That removes an entire tranche of problems with the language. Versus typical google queries - C++ "modern cmake" or java "how do I create a fat jar".

No developer should have to spend their time messing around with build systems.

Interestingly, the README's author seems to agree with you, at least in part[1].

[1] https://blog.frankel.ch/final-take-gradle/

I originally hated Gradle due to its sheer complexity, but there was an incident that I was put off by Maven. I realized that even with the simplest configuration possible, Maven tried to re-create a `.jar` file on `mvn package` every time even when I didn't change any files. Maven is famous for not utilizing incremental builds well and this shows. The strange thing is that incremental builds in Maven sometimes work. I could not find the rules behind this. These unpredictable behaviors make me nervous when I use Maven. Gradle is extremely complex and its behavior changes between versions, which makes my life harder, but at least at a specific version, Gradle's behavior has been stable. Just my two cents.

Maven’s added incremental builds as a full feature in recent versions and it seems to work pretty well.

Nice. This is literally the one reason I preferred gradle to maven. For our bigger projects maven simply took too much time.

Incremental builds and test caching (plus that nifty UI) were always two things that made me strongly consider switching to Gradle.

There are only two reasons to use Gradle.

Android ecosystem, and those that failed to learn from Ant.

> Case in point: The length of the README in this "Modern gradle" reference repo - that's a lot of complexity just to get dependencies, compilation, tests, and packaging. I prefer to copy-pasta some XML fragments and move on to solving the high ROI business-value issues.

The repo is a reference Gradle and Maven repo. The author, in his linked opinion piece, agrees with you:

> Gradle brought the two above great features that Maven integrated, proving that competition is good. Despite this, I still find no benefit of Gradle.

It looks like most people commenting here, would be better off reading that article and commenting. I would (like another commenter) like to see a comparison to bazel as well - and maybe a discussion of how/if Maven could be reasonably used with Kotlin/android...

https://blog.frankel.ch/final-take-gradle/

I prefer Gradle but I do agree with this assessment. Maven is really rock solid and dependable and once you have a POM that does what you want it will keep doing that for the next decade.

I think if you have a project in an enterprise setting where you want a dependable build on a codebase that has a lot of people with relatively low investment contributing then you either use Maven or you have to be very strict and disciplined with how you setup your Gradle build(s).

BUT. For myself I wouldn't trade Gradle for the world. I can setup my projects to develop in a live coding style even though I am working in a compiled language.

Right now I am hacking on a Kotlin Spring Boot project with JOOQ and HTMX and I have set it up so that I can use JOOQ code in buildSrc[1] to output SQL that is then used by JOOQ codegen[2] to generate Records, POJOS, DAOs and so on. I just run 'gradle build -t' and my and 'gradle run' in parallel and because of Spring Hotreload and using the LiveReload Chrome extension I can see my changes taking effect in almost real time. When I make a change that leads to a compile error then my build script will give the Star Trek computer error chirp. I don't think I can convey how happy and productive this setup makes me.

It would be extremely hard to do all of that in maven but it's so simple in gradle. And if you do it right, which is not hard if you follow the docs, then you automatically have dirty checking / lazy behavior. SQL is only generated when buildSrc changes. JOOQ artifacts are only generated when the SQL changes. Spring only reloads the application when code or resources change. Everything is quite fast too. For my project it's currently around 3 seconds from changing the code to seeing my changes reflected on the frontend. And everything from the DDL (schema definition) to DML (sql queries), backend and frontend is in my favorite language: Kotlin!

I hope that everyone's build tool makes them as happy as gradle does me.

[1] buildSrc let's you write custom Groovy/Kotlin/Java build tasks that you can then use in your project's build

[2] with the artifacts that JOOQ codegen generates it's possible to use SQL in a fully typesafe, database independent and refactorable way. Here is a good one page overview of how to set it up and what you can do with it: https://www.baeldung.com/kotlin/jooq

Definitely not happy with gradle, but using gradle.build.kts makes it at least somewhat bearable.

Unfortunately, maven can get into a state where it will fail to be correct without a clear step first. This never happens with gradle (unless you almost deliberately break something), and correctness is above all else.

I often end up defending gradle because I do think that people fail to understand it still (which is partially on gradle, I agree).

A build system is basically “just” creating a directed graph. If we want to get to target node X, you just execute every transitive dependency of it. To make it fast, you do it in parallel, and only do work that is not currently up-to-date. Gradle is really good at these “behind-the-scene” steps.

The imperative part is only about creating this graph. You can use some imperative code to generate this graph, but otherwise it is completely static, after config phase.

It's not just a gradle reference repo. It's also a maven reference repo. Your "case in point" makes no sense.

Edit: most of the readme has nothing to do with either maven or gradle, but the tools and principles both of them are using.

I'm still with Gradle, but my feeling is the same. Gradle comes with some very good things, but the typical Gradle configuration is an insane mess!

However, not everything is magically better with Maven. It is slower (although the Maven daemon is an improvement), the XML config is a bit verbose and modules are not as straightforward as with Gradle. But the convention over configuration approach (without exceptions like in Gradle) makes maintenance way easier.

It is as if those pushing for Gradle never got the point of why Maven over Ant.

The reference repo even refers to this in the Grade Vs Maven link at the top.

Completely agree with your sentiments, it reminds me of a similar topic that was here on CI tools, and that everyone has a phase of finding their usecase not covered, switching to Jenkins to write their own Groovy workflow and then realising the footguns they've unleashed.

I feel the same. Gradle seems to be more powerful and flexible but it becomes harder to maintain specially if you have several projects since you cando things in different ways the projects end up with different config styles. With Gradle you need to commit to be an expert. Maven in the other hand there is generally only one way and it is easier since projects tend to be more homogeneous.

And with Polyglot Maven [1] you don't even have to deal with all the XML markup either.

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

That is dead afaik. Unfortunate, the Zoomer loves to hate on XML.

For the same reason, I refuse to start another SBT project. Scala is fine, but only through the Maven Scala compiler plugin.

Try Mill!

I took a look but I don’t think I’m the target audience. I’m happy with Maven. All I’m doing is importing Java dependencies to my Scala apps. I’m not going all in on the Scala library and build ecosystem.

Spring Boot recently made Gradle the default build platform. Mad!