It escapes me what positive benefit people derive from dumping their accumulated angst with Maven on a blog, but it tends to happen every so often. Each of these posts tends to expose more about the person that wrote the post than about Maven itself. Here's where I think the most recent post goes wrong:
"I Don't Want to Learn a Plugin API": Bemoaning the fact that one needs to learn the Maven Plugin API to write a Maven Plugin seems like a troll. This reminds me of a story related to me about the architecture group of a large financial firm. Evidently someone made a decision to implement all of the enterprise infrastructure using custom C code because the lead architect, "Didn't want to learn anything new". If you would like to write a Maven Plugin, you will need to learn the Maven Plugin API. We're not apologizing for this.
What he's really trying to say is that he's frustrated that he can't just "write some script" that customizes the build. He can, it's very, very easy. It is called GMaven or Antrun. These are capable plugins, I've seen simple, one-off customizations created in very large enterprise builds. Whoever wrote this blog post, didn't take the time to look at the GMaven plugin, the ease with which someone can customize a Maven build (in Groovy nonetheless) is compelling.
"Dependency Management isn't a Build Step": Yes, he's right. Dependency management isn't a build step. Maybe he's confused Maven with earlier versions of the tool which constantly checked for plugin updates. If you develop with Maven and you reference SNAPSHOT dependencies, we are absolutely going to check the repositories for an updated version. If you develop with Maven, and you are building a released artifact, we are resolving dependencies in your local repository. We are not apologizing for this. Maven resolves dependencies from a local repository, and it checks for updated SNAPSHOT artifacts. This is the reason why you no longer have to hunt down a bunch of build artifacts from various open source projects. (Also the frequency with which plugin metadata is checked is configurable as is checking for updated dependencies).
"The JARs you use are at the Mercy of Maven": Right, you know, he's right the repository is such an awful thing. So awful that the alternatives he provides at the end of the article (Ivy) download the same dependency artifacts from the same repositories. Maven sucks because the Maven community established a common and universal standard for the distribution of open source software artifacts and these public repositories don't contain everything he needs? I just don't see the argument, and I also don't see the problem with people and organizations maintaining a local proxy repository of a public resource. What is cogent about this argument? If you need to deploy and share software artifacts between two groups or two developers, what? should you just craft your own repository format because using the Maven repository format somehow cedes control of your architecture to Maven? I don't understand this at all, and I've heard it before, would he like to go back to the days when you had to assemble a lib directory from a bunch of different open source projects?
"Difficult to Change Default Behavior" - I use Maven to build a book project that contains no Java source code, a series of XSL stylesheets and some XML documents. I also use Maven to build Flex projects that generate custom packaging formats and launch the Flash Player for unit testing, connecting to the various control ports on the Flash Player to gather testing information. Both of these project heavily modify the default behavior of Maven to the point where it is being used to support non-Java projects with custom lifecycles. What he's really trying to say is: "I don't like Maven and I'm unwilling to learn how to use it." I think it is contemptible to write a blog post which simultaneously argues that "the default behavior is difficult to change" and also complains about the need to learn a Plugin API. He could very easily solve his problem (likely with some simple Groovy script) if he only bothered to learn about the tool he so despises. And, if the tool does have a limitation, there is an open community waiting for his feedback and possible participation.
Here's where I agree:
Verbosity is a problem. I stand apart from some many Maven contributors here, but I do think that Maven would benefit from a leaner format. Luckily, Maven 3 is moving in this direction and Jason showed people an example of a Ruby-based POM. Again, way to keep up with the tool. Open source is about involvement, it is about paying attention to the ongoing development and discussion. I'm not going to sit around and read yet another rant from someone who hasn't done a simple Google search for "YAML POM". In addition to the work on Maven 3, Don Brown threw together a quick plugin that will allow you to write a YAML POM.
Maven is Hard to Understand. He's right, learning how to use the more advanced features of Maven is not as easy as following a simple getting started example. The Release plugin is especially difficult to get your mind around in certain situations. That's why we're creating free documentation and soliciting community feedback. When he noticed a problem, when he had an issue with the release plugin, did he find John Smart's explanation of the Subversion bug? Did he take a step back and think about whether the Release plugin was even compatible with the way his project was designed?
We're Used to the Axe Grinding
We're used to the axe grinding when it comes to Maven, it is a widely-used tool that will constantly attract people who don't think it satisfies a particular build aesthetic. It is an established tool that captures a convention that is used by many, and it has opinions. It does work very well, if you invest the time required to learn the technology. It is used in some of the most mission critical development environments and when it is used properly it supports massively scalable development efforts.
The other issue with posts like these is participation. If Maven were a proprietary tool controlled by a corporation that provided no access to a community of developers, a blog post such as his would be entirely in play. What makes Open Source different from commercial software is that it provides a mechanism for participation. If you are having a problem with the Release plugin, there is a place for you to go to look for help and tosearch for known bugs. If you solve your problem with the Release plugin you can then take 10 minutes to document the solution for others in a similar situation. We see very little of this from our most vocal detractors; we see very little participation from people who ratchet up the blog vitriol. If you take the time get involved, you will quickly understand how to solve problems or even if Maven is an appropriate tool.
We are here, we are listening to the praise and the criticism alike, and we welcome everyone's feedback.
