Many people dont appreciate Maven because they get hung up on XML. If you need to do anything in Maven which isnt dead easy to do in XML you just write a plugin in Java which is the language you are coding in anyway.
I wonder if this is a reflection of enterprise processes. Writing a plugin in a previous employer meant creating a new repo, a new CI/CD pipeline, getting it pushed to artifactory, making sure people had the inhouse artifactory set up in their settings.xml, and all that had internal overhead. Also learning the maven plugin API. And nobody on your team would want to, so you'd be stuck answering every question about this feature forever more. Compared to gradle where the same tasks just require a few if statements in a scripting language.
A long time ago I wrote a Maven plugin and decided to clean it up for open source. It got absolutely nowhere because after everything you describe—setting up a repo; learning the Maven API, which is one of those expansive APIs that has a lot of metaphoric semantic constructs—distributing it involved getting it into Maven Central by which point I had run out of time/mental bandwidth and never made it happen.
Compare if I had been using Gradle at the time: I would have just coded it up in Groovy, a language I thoroughly enjoy, right there in setup. There are some things I don't like about Gradle, but there's a lot it has going for it, too. Personally, I like XML and enjoy Maven for situations where existing plugins are enough—which is 99% of the time—but that lack of flexibility can be constraining when existing plugins aren't enough.
I find that little hurdle actually improves the quality a lot. It means people don't write maven plugins for every single conceivable scenario; usually there will be at most one or two plugins for whatever you wanted to do, properly documented and maintained, whereas with gradle there will be four or five different plugins with no documentation each of which only covers half of the task. And forcing people to put logic in actual released plugins rather than ad-hoc one-liners in the middle of the build definition means you avoid ending up with a bunch of ad-hoc one-liners scattered throughout your build definition, which is much better for long-term maintenance.
Yeah for sure, and that's what makes Maven a great tool at the end of the day. It's just those instances you encounter rarely where existing Maven plugins are not enough that I've wished I was using Gradle so I could drop a few one-liners and be done with it. I really like Groovy so any excuse to write some Groovy is always tempting. As you say, a few one liners here and a few one liners there can make a build incomprehensible. So people need to recognize that and keep their Gradle builds approachable if they're going to be doing that. It's pros and cons.
if you had made the groovy script in gradle, the code/capability would not have been sharable to anyone else but this single build (other than copy/paste sharing).
if you had the same code as a maven plugin, it would've been instantly sharable, and easily updatable centrally via a release process (as maven plugins tend to also be built with maven). Upfront work, but for long term reward.
>Writing a plugin in a previous employer meant creating a new >repo [..]
I just used the maven groovy plugin to invoke a groovy script containing the functionality instead of a maven plugin (a few lines of code). the groovy script was part of the source code and therefore easy to tweak. A lot of maven variables from the project are accessible from the script. Yeah, it's not really nice.
