Debate: Is Maven the right tool for builds?

by Ryan Slobojan on Jan 30, 2008 |

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:

  1. Poor metadata in the central repository - If dependencies are fixed based on user feedback, then the repository metadata will become much cleaner
  2. 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?

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Umm... "Dan" Brown? by Don Brown

Who is this "Dan" Brown taking credit for my work? ;)

It is not that difficult by Vikas Hazrati

I am not sure if the entry barrier to try out maven is huge. Once i started using maven on my projects I use it right from creating the project structure onwards (vikashazrati.wordpress.com/2008/01/28/quicktip-...). It is pretty straight forward once I got used to it and now I am scared to look at projects which are built using ant or any other build tool ;)

Vikas Hazrati
vikashazrati.wordpress.com

Documentaton is the key by Luca Botti

The maven issues stems from a couple of misconceptions: that it is a script system like ant (hint: it isn't), and that everybody understands perfectly the dependency management behind it (another hint: not really).
The first: trying to work scripting maven like ant will be a real pain, and often maven build will require (when ported from ant) a refactoring of the project, splitting code in multiple modules and a super-pom. After that, will begin the pain of using SNAPSHOTs for build, even for internal modules: plain wrong, because it will hinder your ability to handle dependencies correctly.
That said, we go to the latter point: dependency management. Modules building and dependency handling mandates the "release early, release often" mantra, yet all of us instead of releasing a .94.3.10 will continue with the default 1.0.0-SNAPSHOT, breaking havoc in our builds. Unfortunately, even plugins maintainers and open source developers will do so, breaking our builds with external dependencies.
Last note - an internal repository which also mirrors external sites is mandatory. Have a look at JBoss Maven Build system (yes, they do...): before the dry-run release, they ensure that the build is repeatable through their own repository only. Not the local file system one, the JBoss internal (and externally available, as well) repository.

Mostly works but.. by Kristof Jozsa

On one side I think Maven is fine and once you decide to learn its ways and follow it, you'll get an easier build. In recent months we converted two of our bigger projects into maven2 builds and are quite happy with the results. On the other side, the docs are lacking (and you never know what's up to date and what's obsolete), a company repository/proxy is really necessary (hint: apache archiva), and some plugins are really problematic.

A real life example is that I spent about 3 hours a few days ago trying to deploy a project artifact to a Tomcat 6.x server and ended up with running ant goals from maven taking care of that. I know Maven had a rough path getting here but one still wouldn't expect such problems with such a simple task and a build tool generally available for years.

Great tool by Ivo Limmen

Maven is a great tool. The only problem is: you can only use it if you know all the ins and outs of it. It's like crossing the road: you don't stop half way, you cross it or not. Maven is a complex tool that simplifies development hugely. I will never use any other build tool ever again.
I admit that Maven has it's flaws too. Nothing is a 100% bug free. There are a lot of plugins from Maven 1 I would like to see ported to Maven 2 (vainstall for instance).

Re: Umm... "Dan" Brown? by Alex Popescu

I assume it may be your other inner self working to improve maven :-).

./alex
--
.w( the_mindstorm )p.
Alexandru Popescu
Senior Software Eng.
InfoQ Techlead/Co-founder

Re: Umm... by Don Brown

Actually, that would help explain my intense love/mostly hate relationship with Maven...

What about a decent GUI by Cristian Pascu

Why is it in Java world that we always build tools that let users live with XML configuration files and expect that sometime in the future a decent IDE support will be available. What's so hard to understand that the adoption will be much easier if the tool itself would provide the default application to let visually interact with it?

And in the same time, 10+ years after first versions of Java, is Sun still not aware of this jar dependency management hell that we, programmers, live every day?

And in the same time, with all the effort put into thousands of features of all Java IDE's on the market, features that are hardly relevant when it comes to project setup, build and deploy, can't we solve the basic needs of project before the "three clicks line select" kind of feature? Shame on me, but after 3 years of using Eclipse (IDE, RCP, OSGi) I am still not able to export a Jar from my Java project.

As Matt says, Maven addresses a good problem in a not so fortunate manner.

Re: It is not that difficult by Evan Worley

I agree that using Maven is not difficult. There is a learning curve with every technology you use, and the time spent learning Maven will repay itself in orders of magnitude. One of the comments in the article called out that no one could possibly remember how to properly create a new maven project. This is why Maven created Archetypes. Archetypes are project templates and can be used to quickly generate skeletons for new projects. Your project is different from all the archetypes you say? Then simply make a new archetype, once.

We went from an ant based system to a completely built with Maven system. Even more we have a system that uses Maven to build our java components and NMaven to build our .net components. As with any new technology, we've struggled and learned, but compared to what we had before, I am absolutely thrilled.

Maven can become complex, but it's traditional use is extremely simple. I think a previous author said it perfectly, Maven is not fun when you are trying to shoe horn your setup into Maven. Maven was designed with the assumption that all java projects are similar, and I tend to agree.

Just my two cents and my experiences,
Evan Worley
evanworley at gmail dot com

Javen by Thomas Mueller

What if the build configuration would be Java source code? You have autocomplete, Javadocs, you could debug your build. Part of it would be procedural, part by configuration, part convention (you could override the default by writing a method). Maven repositories could be re-used, but dependencies are Strings (no XML). Example simple build file Build.java
import org.javen.*;
public class Build {
public static void main(String[] args) {
setAppName("acme");
build();
}
}

Re: Javen by Tom Adams

There are other build tools in a similar vein. Gant for Groovy and buildr for Java (there's some others also). There's some Scala tools that are in development, such as Sant and Obi (disclaimer: I'm the creator of Obi), which will (eventually) support Scala and Java projects.

Obi was started as an attempt to get around the frustrations that I'd (and others I've worked with) had with tools such as Maven and Ant. The beauty is that by using Scala, you get the DSL succinctness and flexibility of a tool like Rake (i.e Ruby) combined with the type safety of Scala.

Obi's definitely not anywhere near useful enough to use (its only "task" is Javac) but a decent underlying design (and language) provides the ability to layer things like dependency management "on top" of this base.

Re: Javen by Thomas Mueller

What I like to have is something written in Java. buildr is for Ruby. While Scala may replace Java in the future, it doesn't have the tools support yet. We can talk as soon as it has autocomplete in Eclipse ;-)

Re: Javen by Martin Gilday

buildr is for Ruby.

Buildr is not for Ruby. It is written in Ruby to build Java projects. It uses the Maven directory structure and repositories.

Re: Javen by Alex Popescu

You should take a look at the latest versions of Gant. It tries to cover both Ant and Maven models, and so you'll have access to both words.

./alex
--
.w( the_mindstorm )p.

Re: Umm... "Dan" Brown? by Ryan Slobojan

Hi Don,

Please accept my apologies for the typo - I've updated the article to correct that, and your nemesis "Dan Brown" no longer has the credit. :)

Thanks,

Ryan Slobojan

Too rigid by Ken DeLong

My beef against maven, besides what everyone else said, is that it's too damn rigid. If you want to do something slightly outside the prescribed build process, it's incredibly difficult. Like another blogger said, try filtering your web.xml file. Or try extracting the classes from a WAR project into a JAR project. Or creating multiple distribution units. Or ordering plugins within a phase. A lot of time in a build, the order of operations matters. :-) Every Maven customization on my projects engenders mass panic, and only the bravest venture into writing plugins, etc., and always emerge cursing at Maven.

As for documentation, take a look at the assembly plugin. Every single goal has the same description: "Assemble an application bundle or distribution from an assembly descriptor." Great. Have fun everyone.

Maven makes the hard things easy and the easy things hard.

Re: Too rigid by Shane Witbeck

This is precisely why I've adopted Buildr instead of Ant or Maven. It borrows some of the ideas from Maven like a standardized directory structure and use of the public Maven repositories while still being flexible. Buildr has been a great way to learn Rake and Ruby while greatly simplifying building, packaging AND deploying projects.

Critical mass by Andrew Clifford

The reason behind this discussion is that Maven2 is hitting a critical mass. A lot of opensource projects are migrating to it - worts and all. There is an upfront cost of learning maven2 that the documentation clearly doesn't address. And there needs to be best practices around levels of dependencies, repository management, SNAPSHOTs, etc...

In the long run and in my experience, Maven2 allows you to decouple, modularize on a finer grain, scale more projects, and adopt opensource and internal projects faster. Reusablility and substitutability is happening whether you plug into another project or a project plugs into you.

Best practice 1: Follow the convention. If you don't it's a build smell. You won't scale or get the benefits.
Best practice 2: Don't trust the network - Maintain a local repository so you can build now or a year from now. Online/Offline.
Best practice 3: Stick to building deployment units by 1) Keeping it simple 2)sticking to simple goals clean, compile, test, install, deploy. Don't add lots of edge-case plugins

Re: Mostly works but.. by Ivan Luzyanin

It is very easy to run tomcat from maven using cargo plug-in.
Here the link: cargo.codehaus.org/Maven2+plugin#Maven2plugin-g...

multiple Environments by Arash Bizhanzadeh

I am in the process of upgrading our current build tool from Ant and Maven 1 to Maven 2. As a new comer to maven; it is a real pain!
Just as an example loading a property file in maven is incredibly hard; and you will think it is a very natural thing to do, after all everybody needs to adjust his paths etc.
But what is really strange to me is that there is no good way you can build your program for multiple environments. And it is what everybody needs. How do you do it ?

Maven has two things wrong: by Dominic Mitchell

Firstly, the user interface is completely and utterly counter-intuitive. Try some of the following:


  • mvn

  • mvn help

  • mvn --help | grep -i goal

  • mvn --help | grep -i phase

  • man mvn

  • mvn pakage



The errors are completely worthless. And of course, when you do figure out what the hell you're doing, it only gets better. Screens and screens full of idiotic crap that you don't care about, errors go flying past (yet don't appear to be a problem and don't stop the build). It's a complete shambles.

Secondly, it's the failures. When something goes wrong with maven, it's usually near-impossible to tell what the actual problem is.

This is all very frustrating, as I can see what Maven's trying to do for me, and I want that. But as a tool, it's bloody awful.

Re: multiple Environments by Roman Pichlik

You should definitely look at profiles, they are targeted for these use case. I also recommend to you take a look to the book Better Build With Maven.

Re: Documentaton is the key by Renato Cavalcanti

Indeed documentation is the key, but unfortunately Maven and its plugins are not well documented.

If someone is looking for a good source of information about Maven, simply go to www.devzuz.com/web/guest/products/resources, register and download their book "Better Builds with Maven".

Very often I heard people complaining about Maven. I don't have a lot of experience with it, till now I have only worked in two projects with Maven.

My first experience was a bad one and I had the feeling that something was wrong with the way we were using it. I was always fighting with the dependencies.

I'm now having my second experience with Maven and I'm convinced that's a very good tool. It simply works! And when it doesn't it is not because it's buggy, but because I did something wrong.

Once you understand how it works, you don't get in trouble. The problem with Maven in my opinion is that most of the people that is trying it has a Ant background and as Luca Botti said, Maven isn't a script system like Ant. It's a matter of mind switch, if you want to move to Maven, prepare yourself to something totally different.

Re: multiple Environments by Arash Bizhanzadeh

I looked at that and i am using profiles. But I need to pass some parameters to maven so that it could understand difference between my different environments, but without any luck so far. Unless I write all the parameters inside POM file which is a really ugly solution

Re: multiple Environments by Erick Dovale

There are also properties in maven. Different profiles can have different values for the same property.

Re: multiple Environments by Arash Bizhanzadeh

The point is you need to write that parameters directly in the POM file. And that is not what you want to do when you have a dozen of them. I am looking for a solution to put all my properties simply in a property file for each environment and load them within profiles.

Mailing list is helpful by Evan Worley

I understand it can be hard to find the right documentation (if it exists). I have had good luck using the maven users mailing list. For anyone who is trying to do something in maven that seems overly difficult or awkward, try throwing it out to the list to see if there is a better way. For example, the previous author who said it is really hard to setup a new project would've quickly been informed by the users list that archetypes can make this a lot easier.

maven.apache.org/mail-lists.html

Re: Javen by Eelco Hillenius

You mean something like Gosling? Read more on Tim's blog.

I don't get it by Eelco Hillenius

I don't get what is so difficult about Maven. It's certainly not perfect, but for average use, it's really really simple. It only gets anoying when you try to bend it to your will too much, and it is the whole point/ improvement that people stop doing that. I'm just thankful that nowadays I can just check out a project and have it building right away. What a difference from when people were using their own exotic Ant builds.

Re: Umm... by Michael Bushe

Don - maybe you should take credit for "The Da Vinci Code" :-) I'm guilt of a similar mistake today. :-)

Is there any viable alternative for complex projects? by Frank Hardisty

If there aren't any alternatives that would serve, then there's no need to agonize much about Maven's shortcomings. From my point of view, the things that are really compelling about Maven are things that Java lacks -- dependency management and versioning. The "convention not configuration" thing is nice too -- although there is plenty of configuration to do in a POM.

The reasons that Maven is seen as a PITA are 1. The fact that it does not work well with the leading development tool in Java (Eclipse). Even if it is Eclipse's fault, it's a big turnoff for many developers. 2. The documentation is lacking in many places. 3. bugs.

I think there is also the fact that Maven is a complex tool designed for complex projects. So it does feel a bit heavyweight. If I'm evaluating a project for possible use, and it is built in Maven, I kind of flinch, just because I know that although the project may be cool, it is probably not a quick study. This is not Maven's fault, in fact Maven makes the situation much better than it would be otherwise by firstly having a standard layout so you can find your way around the source, and secondly by listing all dependencies etc. in a standard place so you can find them. But, few of us love complexity for it's own sake.

Re: Mostly works but.. by Kristof Jozsa

Thanks Ivan, I was aware of that. Unfortunately it aint help much when you'd like to use Tomcat6..

Re: multiple Environments by Erick Dovale

There is also profiles.xml where you should define all profile specific stuff.

Re: Umm... "Dan" Brown? by Musachy Barroso

your evil twin? :)

Two words: Use Artifactory by Ryan Gardner

Waiting for the main repository is a PITA. Artifactory saved my marriage... err... builds

Re: Critical mass by Rainer Eschen

That's it. Maybe we can add:

Best practice 4: Have a plan. Think about artifact structure, the build and deployment process, first.

And for all Ant power users:

Best practice 5: Never think about to solve the problem in Ant. Skip all your Ant work, first.

The convention stuff is powerful. You'll recognize this when having a look at other Maven 2 projects. When I thought about adding ICEfaces to AppFuse it took me two days to do so, whereas the most time I was fighting with the web.xml. The pom.xml stuff was the easiest part:

icefusion.googlecode.com/

Lacks simplicity by venkataramana madugundu

I have had some bitter experience with Maven. Personally I feel, too much control lies with Maven rather than it giving control to users. I understand discipline is the key in bigger projects, but one should also understand that programmers do not like BIG BLACK BOXES like Maven. It is more of a framework...and my experience says "frameworks in the pursuit of solving some bigger problems actually become problems of their own". So I would rather like raw ANT scripting than a framework.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

37 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy