The need of automatic downloading artifacts (mainly jars) broke everything, the Ivy system seemed the obvious step forward, but people liked more the "false" simplicity of Maven.
I'm a developer, a developer needs to play with APIs, and a nice environment to compose those APIs and create new custom APIs. In the same time a build system must be structurally declarative, must have "join points" to help IDEs to understand the project structure and provide UI access to build tasks. NetBeans made a good job in this case creating a "standard" Ant structure and in the same time leaving room for developer customization.
But unfortunately Maven won...
Maven won the "new generation" of build tools going to replace Ant.
Maven is a friend of IDEs but a terrible tool for developers. The need of making separated plugins IN JAVA to customize your builds is the worst nightmare for any pragmatic developer who loves the tools that promote freedom.
Yes Maven has provided standardization, but a Stalinist standardization. A signal of this contempt to the developer freedom was written in Maven web site when talking about Ant support in Maven, instead of embracing Ant as a basic extension to avoid to reinvent the wheel, Ant is despised in Maven documentation (in spite of supported).
I recognize automatic jar downloading is nice but the price paid has been very high for years.
There're many anti-Maven articles (of course there're also many Maven lovers), this is just one:
"Which is why every project eventually hates Maven. Maven is a classic contextual tool: it is opinionated, rigid, generic, and dogmatic, which is exactly what is needed at the beginning of a project. Before anything exists, it’s nice for something to impose a structure, and to make it trivial to add behavior via plug-ins and other pre-built niceties. But over time, the project becomes less generic and more like a real, messy project. Early on, when no one knows enough to have opinions about things like lifecycle, a rigid system is good. Over time, though, project complexity requires developers to spawn opinions, and tools like Maven don’t care."
Maven Stalinist approach is one reason of why very important JVM players in tool development never have used Maven as the primary development option in spite of the pressure of Maven "success". Players like Liferay, Vaadin, GWT, Groovy/Grails, Android and other names I don't remember. Most of them are now replacing their custom build system to adopt Gradle bypassing Maven.
I'm an open source serial developer, I've done many developer tools (http://www.innowhere.com for a list), I love coding and I love the helpful things that IDEs provide to developers like structural code search (References/Find Usages) and refactoring, I try to be a friend of IDEs, this interested friendship pays off in productivity. For me IDE good integration of the language/framework is not an option, and as a single cowboy developer I have no need of continuous integration stuff.
The boring part of software development created for public use is releasing and documentation, I must do it in spite of I don't like it very much, this is why I want easy and developer friendly tools.
In an Ant world packaging was not a problem, I like to provide a simple zip with jars, javadoc, manual in PDF or HTML. This "simple" task is affordable in Ant... near impossible in Maven, the lack of freedom of Maven in this area is so terrible that I still use Ant (maybe in a future I might migrate to Gradle).
Yes, you can avoid Maven, you can use the build system of your preferred IDE or if you are lucky doing Android development you can use Gradle and Android Studio or IntelliJ (unfortunately Gradle support is not so great in other not IntelliJ based IDEs). I don't know very much of Gradle, but I have a very clear intuition, I'll be able of doing ANYTHING with Gradle!
The problems start when you feel pressed of publishing of your artifacts to Maven Central. Maven Central requirements are very Maven tool centric in spite of you only want to upload a simple jar. If you can't follow the Gradle path (because bad support of your IDE) you are forced to follow the Maven way of life...
Maven again has... won.
I think for myself "you can do it guy, everybody does, cannot be so complex, yes you're a bit dump but not so dump".
I'm not new following corporate steps to bring something to public, in my current job I've uploaded many Android applications and many releases of these Android applications. Just need to create a key pair using Java, only once, sign you .apk file with a tool provided by Android SDK, some required zip alignment using an Android command, and upload it using the Google Play web UI. The Android documentation of publishing process is clear and simple.
I have absolutely no problem of using a web UI when I must to do something from time to time, I have no need of automating absolutely everything (for instance and I don't like to put keys in source code or configuration files).
Plenty of self-conviction I start to read Sonatype guide, that is "the guide" . Minutes later my mind starts to break "I can't believe how complex is to upload a
Maven again has... won.
One thing that disturbs me is the need of installing GnuPG, "no, no, no, I can't believe a JVM tool relying on an external tool".
Instead of following the official path of Sonatype I try to find a short path (remember I want to publish free stuff)... bad luck, I find pages like this
(relying to Sonatype docs) and this, this last article makes me even more angry because beyond GngPG I must install, FOR A JAVA TOOL, an external program named Rultor, installed by using the Ruby gem installer...
I say to myself "be patient, there is no short path, follow the official path", but when I read things like this:
"If, for some reason (for example, license issue or it's a Scala project), you can not provide -sources.jar or -javadoc.jar , please make fake -sources.jar or -javadoc.jar with simple README inside to pass the checking. We do not want to disable the rules because some people tend to skip it if they have an option and we want to keep the quality of the user experience as high as possible."
That is, you must provide a sources and javadoc jars even there is nothing inside to keep the quality!!!
Ok Maven, you won, according to Sonatype requirements I make a POM including sources and javadoc generation.
In the process of javadoc plugin configuration, I can't understand why folder filtering does not work, soon I realize Maven does not clean previous generated markup, now I understand why Maven Clean is your best friend (and a signal of tool mediocrity).
Time to read next steps for Maven... finally I've got tired of reading how complex the POM becomes... the serious problem of Maven is the excessive declarative approach as explained before, which makes over-complex any attempt to code any sequential task.
Fortunately when searching for how-to articles and commenting in Twitter, @jbaruch an employee of JFrog contacts with me offering Bintray.com alternative to publish to Maven Central, the people behind JCenter, I read the article "The easy way to maven central" and I was sold. Bintray provides a GUI to upload and self sign your artifacts if you provides your public and private GnuPG keys, and with a simple UI action you are published in JCenter repository, and providing your Sontaype user and password you can finally easily publish in Maven Central.
Bintray helped me to break the wall of Sonatype process. I'm saved!!
Currently I've released RelProxy on JCenter and Maven Central. For releasing I use Ant calling to Maven tasks to generate the required Maven artifacts and to generate a distribution zip with everything. Everything could be automated, I could add signing and uploading from Ant (or maybe by the POM) without Bintray, but Bintray auto-signing and uploading UI is enough for me, releasing is done from time to time and most of releasing process is already automated, and releasing in JCenter is a plus.
Note: Don't forget JCenter, for instance Maven Central is no longer pre-configured in Google Android environment.