Debate: Is Maven the right tool for builds?

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

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

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.

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.

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).

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

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

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.

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

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();
}
}

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.

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 ;-)

buildr is for Ruby.

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.

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

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.

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.

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

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

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 ?

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

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.

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.

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

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

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.

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

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

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.

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

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.

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

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

your evil twin? :)

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

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/

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.