Recently, there has been a lot of debate around the usefulness Maven, which is a Java-based build and dependency management tool being used in many projects. InfoQ took a closer look at this debate to understand what issues are being encountered, and what has resulted from the debate.
Howard Lewis Ship, creator of Apache Tapestry and Apache HiveMind, recently posted a blog entry in which he described several issues which a project he is working on has encountered while using Maven:
In both Eclipse and IDEA, the Maven support has been very slow, buggy, and unstable. IDEA 7 gets it a bit more right than Eclipse (with the 0.0.12 Maven plugin) because synchronization is explicit. Still, it seems to turn into an endless amount of tweaking, fixing and praying, to keep things operational.
At the core, Maven has a great idea (really well thought out dependency management) saddled with an obnoxiously bad plugin system for performing the build. The obnoxious part is that a build that works on Monday may fail on Tuesday because some new, broken plugin was released into the central Maven repository.
Ship also described a lack of documentation as a major hurdle to understanding and using Maven, and recommended Ivy as an alternate dependency management system. Eugene Kuleshov pointed out that putting plugin version numbers into the Maven pom.xml would fix the broken plugin issue, and Charles Miller replied that this advice was nowhere in the Maven user or setup guide.
Don Brown also recently posted about a new Maven build which he has created and which addresses several of the issues which he sees in Maven 2, including the addition of HTTP connection pooling and parallel artifact downloading. Work is ongoing on this branch of Maven, and there is hope that the changes will be reintegrated into the trunk.
Others have also weighed in on this debate, with Jonas Fagundes questioning why Grails does not use Maven, and commenting:
Maven is a fantastic tool, the type of tool that we wish to exist in every language. It's a modular project build tool. It is able to manage dependencies, build cycle, testing, packaging and publishing your artifact in the repository. It's a project build tool, a step ahead of the normal build tools (actually the first version was a layer on top of Ant). It provides a default directory layout for your project and really nice defaults, all you need to start is choose a name for your project and the default package to create. Everything else works out-of-the-box and if you need anything different you can provide configuration in the last case you can provide a new plugin that will be managed by maven repository (the plugin is just another type of dependency and it will be download automatically after you configure in your pom). It uses convention over configuration much before rails community coined the term.
Graeme Rocher, CTO of G2One, replied to Fagundes and described why Grails did not use Maven, saying that the main idea of Grails is simplifying Java EE:
Now Maven is the complete opposite of this. Why do I have to go and read their manual everytime I want to creating a project. I mean there is no way I will remember all that crap and their documentation is pretty appauling to begin with.
I think only Java people would be willing to accept a build system like Maven with all its complexities. Any other community would be like "what the hell is this?". For me Maven is the EJB2 of build systems: over complicated, over engineered and requiring an intelligent, code generating IDE just to work with it.
Rocher also indicated that Maven support in Grails exists, but that it is not the default and he suspects that it will eventually be replaced by other build tools such as Gant, Raven or Buildr
Matt Raible posted a follow-up to Rocher's post, and indicated two major problems, and potential solutions for both:
- Poor metadata in the central repository - If dependencies are fixed based on user feedback, then the repository metadata will become much cleaner
- POM.xml as the source of project metadata - XML and the verbosity that pom.xml requires makes the build difficult to parse, and the ability to specify the project metadata in other formats such as Groovy would ease this
Raible also added:
I'm still a Maven fan, mostly because it's greatly simplified the maintenance of and releasing of AppFuse. When I do GWT, Seam or Grails development in the future, you can be sure I'll try to use Maven to do the development. Why? Because I've learned how to use it and I don't feel the pain that so many others talk about. I also think it really shines on really large projects (builds that produce 30+ WARs for example). An Ant-based system on really large projects can become quite burdensome and difficult to maintain. Not only that, but it's very difficult to maintain a modular build system (where you can build/test/deploy a single WAR) with Ant. In my experience, really large Ant-based systems take forever to process that everything is up-to-date whereas Maven systems depend on each other and require you to keep them up to date. Sure it requires you to be smarter and run "mvn install" on your subprojects, but I'd rather do that than wait 5 minutes for Ant to process everything just to run a test.
Some other quotes:
- boomtown15 -- I can't believe that people give up on Maven so easily. It is actually really simple if you follow the conventions. Ok, that first project setup is a bit rough and I agree the learning curve is a bit steep, but I believe the benefits outweigh this.
- Xavier Hanin -- So, am I a Maven advocate? Yes and no. I like the idea behind Maven, being able to build a project in a standard way is really neat. What I dislike is the lack of documentation, flexibility and robustness, and that there's just too much black magic.
- Les -- [...] it never ceases to amaze me at the blow back against maven. Maven has a higher initial learning curve, but the payoff is more simplicity as things get more complex.
- Tech Per -- While I do agree with you, that maven can be complex, is over engineered and lacks good documentation, I still have a feeling, that maven is the best thing around. I use maven each and every day, and yes, I bitch about it. But I have also tried to go back to ant (which I also know quite well), ... and it was a PAIN. Then, I saw how much I get from maven.
- Ortwin -- We are using Ant now for big stuff, because it takes just too much time and knowledge to maintain a Maven build. Even the Ant build is not very simple, but at least it doesn't break all the time. Next time I'll resort to Bash scripts. All this programming in XML is just a major PITA
- Steve -- Netbeans Maven support is ahead of any other IDE that I've seen, use it daily on moderate sized projects. Maven brings so much to the table, I wouldn't think of dropping it. Sure there's been some investment in learning how to tame it, but once you do you find there are simply no alternatives. dependencyManagement blocks to save yourself surprises, purpose-based profiles, understanding the build lifecycle stages, and being CAREFUL about what repositories you add, these are all key to taming the beast.
- Kevin Menard -- The SNAPSHOT system just doesn't work, IMHO. When used properly, it can be a great way for a project to let early adopters test things. All too often, though, it's simply a crutch preventing a formal release.
- distiller -- [...] I used to evangelize Maven but have since become an Ivy advocate. Ivy is far more flexible on how you setup your repository and, because building is delgated to Ant, Ivy doesn't try to dictate your project structure like Maven Does
- Jay -- [Howard Lewis Ship], your criticisms are valid and I've been burned in many ways the same as you have - downloading broken releases, documentation that is flat-out lying, etc., but what's an alternative? Give me another tool that uses convention over configuration, dependency management and copius plugins and i'll consider it. At this stage, it seems energy would be best directed towards addressing your issues (The documentation issue is particularly atrocious) rather than starting from scratch.
- Jon Scott Stevens -- [...] take this as a note... we have been interviewing a lot of people for java developer positions and not one single person that we have interviewed has had a truly good thing to say about maven.
- Peter Backlund -- Maven is a very useful tool, and has worked very well for me in many projects. You will however need to adjust to the Maven philosophy, or else you're problably going to get burned. If you have the attitude that "Here's my way of organizing a project, and now I'm going to shoe-horn Maven into doing that!", you will be in a world of hurt. If you instead work with Maven, a lot of good things will come for free.
- Matt Raible -- I don't think anyone thinks that Maven is a bad idea - it's just a poor implementation of a good idea.
- Rick Hightower -- Every day I curse Maven. Every day I praise Maven. I hate it and love it all of the time. I remember although it could be better it is a far cry from using Ant. Since I travel a lot and consult/develop a lot.... I have seen so many snarly Ant build scripts. At least with maven, I have to just tame one beast and one philosphy. With Ant, it is random beast with many heads.
- Bryan Taylor -- There's certainly some innovative ideas in Maven, but there's also some things that scare me. It's funny that Maven's reliance on "convention over configuration" easily predates the Ruby on Rails fad, but the latter gets all the credit for inventing it. There's a reason for that.
What do you think?