The Things That Are Wrong With Maven
Posted by Anders Sun, 26 Oct 2008 16:26:00 GMT
Last week I attended a small workshop on building with Maven, which quickly turned into a Buildr workshop once we realized that most attending simply didn’t like Maven very much. It inspired me to write down some of the things I don’t like with Maven:
Verbosity
Maybe the problem is spelled “XML”.
Buildr shows that you can express essentially the same things as Maven’s pom files in an order of magnitude fewer lines and still be more readable. Good old Ant has the excuse of being created in a time when XML was hyped, but there’s no excuse for the masses of XML that Maven forces you to create and maintain.
Working With Legacy Code
Have you ever tried to introduce Maven to build a large legacy system? Because of Maven’s inflexibility, you can’t easily do this in small steps, incrementally moving closer to (Maven’s idea of) an ideal file and dependency structure. Instead you’re looking at doing it all in a single huge, messy, risky step.
Transitive Dependencies
Nice in theory. In practice this means Maven will download half the internet for you and at the same time making you sensitive to every minor slip-up in any pom of any n-level indirect dependency you have. Even if your code never invokes the rarely used parts of commons-something that actually depends on commons-kitchen-sink, you’re going to get commons-kitchen-sink. Or maintain the screenful of XML to override it.
Flexibility and Plugins
Most non-trivial projects have at least one detail that just doesn’t fit Maven’s model. In any other build tool that can be easily remedied with (often just a single line of) scripting. In Maven, the solution is plugins. So your build ends up depending on abandoned third-party plugins just to accomplish the most trivial scripting tasks. So much for dependency management.
Unit Testing
When unit testing, you are only interested in two things: Are my tests at 100% and, if not, what is failing? (And, for bragging rights, how many tests do I have?) Just like Ant before it, Maven fails badly at this. The (mostly useless) stdout from the tested code is puked to the terminal, drowning Maven’s own test summaries. The causes of failures, on the other hand, are hidden away in report files in some other directory.
I can see the use for “test reports” in some scenarios and tool sets, but as a default behavior for a unit test runner they’re absurd.
Build Output
Why is so much useless output written to the terminal during a build? Are they trying to impress Linux Kernel hackers?
Repositories
It’s good practice to keep the things you depend on under version control, among other things for repeatability. Maven’s take on this is to keep dependency meta-data under version control, and download the dependencies themselves from public repositories. So now you’re depending on someone else’s public repository to be available (and correctly configured and maintained). If it’s not, you won’t be able to build on a freshly installed machine. I’m told the recommended solution is to have your own local caching repo (which also allows you to depend on private or proprietary libraries). So now you have yet another server to maintain. Wouldn’t it be both less work and lower risk to just keep the jars under local version control?
(Also, the only caching repo I have tried, Artifactory, kept corrupting data. It was probably a problem with its embedded Jackrabbit content repository, but still).
File Structure
I’m forced to structure my files in a way the Maven developers, a group whose judgement and taste I usually dissent with, find ideal.
I could go on all day…
I agree with some of your points. A much bigger flaw is that even after all these years, the documentation, diagnostics, and reliability aren't up to snuff.
Call me old fashioned, but I'm contend when I have to go into an "old Ant" project and know that I need not mess for 2h with dependencies, plugins and other settings. It's just more KISS.
100% agreed. I have tried, I have read books on it, I wanted to make simple ejb applications to deploy to Geronimo and it was terribly what we need to do in order to get it working. As commented before, I agree with the concept and can not find a better way of think in terms of application lifecycle, but in practice, naaaa, Ant still works fine ! Thanks for the post, I felt I was the only one struggling with maven :)
Maven has caused no end of pain for our project. I definitely prefer Ant.
I'm working on moving our company to Maven, and I tend to agree with you on most things. But you're really complaining about trivial things that have no real weight to them. Too much XML! Waahhh! Too many words in my terminal! Waahhhh! Seriously, you haven't used Maven at all if that's what you're complaining about. For the record, I concede that the plugins argument is completely valid. It's a pain, but the point of Maven wasn't to allow developers to quickly create one-time scripts to do something trivial. If that were allowed, you'd end up with, umm... Ant.
I'm using maven for about 2 years. NEVER GOT A SERIOUS PROBLEM. I've 3 projects builded on: - 1 windows XP - 3 windows vista - 2 gentoo linux - 1 suse linux - 1 macosx I'm using all the standard plugins (assembly, archetype, war, etc) plus some fancy plugins, like hibernate3 (in order to build the mapping documentation). I'm also using pom composition and inheritance (DRY, don't repeat yourself). I've also embedded maven to build some parts of another application from java. I've also written plugins on my own (to replace an unsupported plugin) but it was a task of an hour! :-) The *REAL* problem of maven is the DOCUMENTATION and the maven API is still for java2, no java5 features :(
First of all Maven is far from perfect. It has bugs and the documentation is not as good as it should be. But still I find posts like this one misleading. 1. Verbosity Do I need to say anything here? Nothing is wrong with XML...at least not for this taks. It is debatable when too much is too much, but definitely is not too much for a build tool. 2. Working With Legacy Code You can build your project with Maven in parallel with what you have and when you determine it is complete you can make the switch. 3. Transitive Dependencies You can control those dependencies, there is nothing scary about this one.There is a big difference in controlling all dependencies versions and only what's critical for you : application libraries, critical building phases. I don't think it will hurt you if the generated Maven website could be affected by "minor slip-up". 4. Flexibility and Plugins Flexibility means you are flexible to extend the current building process not that it will provide everything for every project. 5. Unit Testing I hope you're using a Continuous Integration Tool, if not I would recommend Hudson or TeamCity(free for 20 build configurations). Who said you have to analyze 10Mbyte of log files to find which test failed? Use a tool for that... 6 Build Output Just hoping you're not running with -X switch :) 7 Repositories Is it too much to have a file system and an Apache HTTPD daemon somewhere? Nobody said to manage your repository with an application, but if you want a better view of your repository your can try http://nexus.sonatype.org/ 8.File structure The current file structure is a recommendation(one that makes sense), you can changed it with 3-4 lines in your POM file. I could go on all day… As I already said Maven is not perfect but still ... Instead of writing blogs like this one, go on JIRA(it is open 24/7) and make suggestions, provide patches or even write better plugins. PS. I'm not a Maven developer, just a simple user.
Somebody that can compare Buildr with Gradle? I'm giving some time to the latest, and am quite satisfied with the results so far. For the record, there have been implementations of a less verbose XML file format for maven, and it was pulled back because of "backwards compatibility". To me, that's a symptom of a project that will not evolve past this current state of dissatisfaction.
Maven is all that is evil with java developers. Like spring. Guice is the cure for springs evil. But there is no similar alternative for maven unfortunately. Perhaps java developers forget that if they move from java into another tool (properties, xml etc) they lose all the benefits of java's tooling... which always ends up in pain. It's like eclipse + osgi = unstable piece of crap.
Both Spring and Guice are good at adapting to your style of development. This is my main complaint against Maven. It forces a style on you that may or may not work with your IDE/methodology etc. Ant is an incredibly flexible and useful technology for builds. My typical build file is about 20 lines max and reuses macros I've created across multiple projects. All directories/parameters are completely configurable as well. Maven is nothing like that. I like the concept of formalizing a project, but I think the implementation is unsatisfying at best. dependency management is a nice thing though, and I'll probably investigate Ivy going forward.
I have used Maven for many years since the beginning of the project and although it has some inconveniences, most of the complaints offered here are common among folks who want to completely customize Maven which works against the whole idea of a Maven project.
Maven has many great features and benefits, but the biggest advantage is the ability to move from one project to another without having to take the time to dig through each project's build to understand it before even getting started coding on the project. With Maven and it's project style, I can move amongst many, many projects without stopping to dig into the build. If you want to customize the project structure or adapt it to a legacy project that doesn't follow any conventions, then yes, it's gonna be painful.
Verbosity - If you're not happy writing XML, then use some intermediary technology such as Groovy that will spit out the XML for you.
Working With Legacy Code - This is most commonly a result of many, many, many projects all crammed into one source directory and using the package path as the separator. This is difficult no matter what build tool you're using. I've worked through these style of projects either by using small hunks of Ant scripts or by creating different assemblies for subsets of a huge project (this breaks it up into smaller modules).
Transitive Dependencies - I've never had much issue with this feature, in fact, I like it a whole lot better than trying to manage dependencies all by hand and checking them into SCM. Regarding the POM errors, the blame for crappy POMs lies squarely at the feet of the projects who own those POMs, not Maven.
Flexibility and Plugins - I've found that there are more than enough plugins available to handle the situations I've encountered. And if I can't find a plugin, I do use some sort of scripting and I don't find it to be a big deal.
Unit Testing - The right plugins and tools can make this task much easier to handle, but I've not found an easier way to work with unit testing yet.
Build Output - Agreed - I'd like to see this be configurable.
Repositories - All I can say is that you need to start using Nexus (http://nexus.sonatype.org/). It will alleviate all of these issues and it beats the hell out of all the other repository managers.
File Structure - This can be customized either using the properties that are available, using the includes/excludes capability or using the assembly plugin. Yes, this is kind of a pain to set up, but when the build structure is non-conventional to begin with, there is no easy solution.
One last suggestion I'll make is for the use of Maven with Eclipse via the Maven2Eclipse plugin (http://www.eclipse.org/m2e/). This plugin dramatically simplifies the use of Maven for Eclipse developers. Anyone using IDEA already has pretty good support and I'm told that Netbeans has good support for Maven as well. I've found that simplifying the use of Maven from within the IDE smoothes the road quite a lot for developers.
I'd recommend the open-source Quokka ( http://quokka.ws/ ) which addresses many of issues you've raised.
@Bruce, maven eclipse plugin is awful. If I do "mvn clean install" from command-line, then the maven eclipse plugin would cry saying that some of the class files on eclipse are not there (not being built, whatever)
Ted, I switch back and forth between m2eclipse and the command line all the time and I don't have any issues.
Too much yelling... Do you really know how to use Maven? Seriously, usually people complain about something like this just because they don't know how to customize or are too lazy to read the docs/sources. I work in a project with thousands of build.xml and I hate it. I wish they've used Maven... :/