> I especially find Maven unreliable in combination with eclipse.
Indeed. I have first hand experience with this. My team has a diehard Eclipse user who has added a bunch of random configuration plugins to Eclipse basically to make Eclipse work with Maven.
Compare this to IntelliJ. You can open a Maven project (even a multimodule Maven project) directly in IntelliJ. There is no project importing/conversion. It just works with the native Maven project model.
There are plenty of things to dislike about Maven but this isn't one of them.
The author is correct about Maven documentation generally being terrible. At one point I wanted to do something as simple as creating symlinks in the target directory instead of copying files. This would greatly ease doing Javascript development, for example.
Well there's a Junction plugin for Maven that alleges to do this. However it hasn't been updated since 2007 and relies on something no longer in a Maven repo that I could find.
But here's the point I most disagree with:
> Maven assumes there is one right way to build for everyone
A lot of people have this opinion (and prefer Ant, Gradle or something else as a result). I do not share this view. I like that Maven is opinionated about things like project structure.
Why? Because left to our own devices engineers are terrible at making these sorts of decisions. We all have a tendency to focus on some weird aesthetic and overstate its importance at the detriment of consistency across teams and projects.
I've had this argument with coworkers in relation to us having a very strict style guide for our code [1]. Opponents call this an obstacle getting in the way of getting something done and it has a cognitive cost of internalizing what is essentially useless information and arbitrary standards.
Obviously said people haven't worked in a large engineering organization where different teams would otherwise have different line lengths, curly brace styles, indenting levels and so on. It's a good thing there's a central set of conventions for this stuff. It avoids pointless "wars" about where curly braces should go.
I feel the same way about Maven's archetypes. Fact is, you can look at any Maven WAR project and know where to find pretty much everything. You can't say the same about any Ant project.
Just like with code style, people have an exaggerated view that their particular way of doing things is right and super-important.
Being consistent is often more important than being right.
Being right is subjective more often than it isn't.
In the end the author states:
> I think Maven works fine but in the past some logical choices have been made that do no longer make sense
which kinda makes and misses the point. He's right in that it does work fine for all its warts. But changing things like XML (for YAML or SBT's DSL or whatever) is pretty much a change for change's sake at this point.
Maven is one of many tools that isn't cool but is certainly good enough. There are really bigger things to worry about. How much time do you spend editing build files anyway?