Buildr, Gradle or wait for Maven 3? [closed]

Question

I am really tired of struggling with Maven 2 all the time. Build tools should not be in the way. Recently I have been looking at Buildr and Gradle. Maven 3 seems to fix some of the struggles. So, what should I go for now? Buildr? Gradle? Or wait a year for Maven 3?

Mill

just a note for others reading this later: maven 3 is now available – Juba

Gradle 1.0-milestone 3 is also available. :) – Referendum

Answer 1

No build system is a magic bullet. I find Maven solves more problems than it causes for me, but I'm quite comfortable writing plugins to get round its shortcomings, I also deal with hundreds of projects, so Maven's inheritance and dependency processing is quite helpful for me.

Browse SO a bit and you'll see Buildr and Gradle both have issues too (same for Ant and Ivy), generally you're trading one set of problems for another and its a case of finding the least painful.

Is there anything in particular that is bothering you about Maven or is it a general itch? If it is a particular problem it is worth looking at the Maven 3 issues on Jira, if the problem isn't addressed, you can raise it, or else there may be little point in you waiting

Coates

Yes, I am aware that buildr and gradle has problems too. The biggest problem in Maven 2 is transient dependencies. It's great when I want it, but sometimes I would like to exclude a dependency globally, like commons-logging. Aslo, some of the plugins I use is really awful to work with. One option is to write a better plugin I suppose :-) – Mill

You can exclude transitive dependencies, though it is a bit clunky, have a look at this page: docs.codehaus.org/display/MAVENUSER/Dependency+Mechanism – Coates

That method is what I'm doing now. Would still like to declare a global exclude. Maven 3 looks like it promises such a thing. – Mill

Instead of excluding I add the dependency with "provided" scope so it doesn't show up in classpaths or WARs. It will still be on the compile classpath though but as long as you don't use commons-logging in your code you'll be fine. – Leesa

You can have a global exclusion, just define it in the top-level dependencyManagement – Analphabetic

The latest version of Gradle is far less verbose and far more flexible than Maven. I agree that Buildr and Gradle also have problems, but for me it boils down to this: easy things are easy in all three tools, but Gradle seems much more flexible than Maven when it comes to doing the custom things that most builds need to do eventually. – Referendum

+1 Maven requires more setup time but has less grey areas for support. – Klagenfurt

One of the less appreciated features of maven is plugin versions. This means that older projects don't break when maven is evolving and bugs gets fixed / semantics changes in subtle ways. The downside is that it loads half the internet the first time you build something because of the number of different plugins. – Expressivity

Answer 2

I wouldn't expect too much from Maven 3. The people behind the Maven pedigree of build tools have always held the assumption that project builds are homogeneous, that is: all build problems fundamentally boil down to the same problem. This view of the world can be held fairly consistently in the face of opposing views but comes at a cost. The absence of scripting logic in Maven ("when you want to script you know you're doing something wrong"), the cumbersome plugin API ("no ordinary Maven user should want to write a plugin") and the central repository ("we all have the same dependencies") are all testaments of this overarching assumption.

In the real world build problems are heterogeneous because people build software for a wide variety of reasons. They all 'develop' like we all 'drill holes' once in a while for solving unique problems. Regardless of your level of abstraction you'll always find similarities when comparing arbitrary build problems. It is the reveration of these similarities and the condemnation of differences that is the downfall for Maven's design and the reason why it draws so much flak. Basically, Maven is authoritarian and utopian in its outlook.

PS: Maven has good features, like convention-over-configuration and the idea of using repositories (the Maven implementation of this idea is troublesome).

Baptistery

I script very complex Maven builds all the time using Groovy. I also have some of the most unique builds - I build books with Maven. The POMs are easy to comprehend. – Analphabetic

You cannot appreciate the importance of an on-site maven repo/proxy until you've worked in a team environment, and you need to chase people to find out what jars they are talking about. A 'third party' repo where people can upload jars to means that everyone will be playing with the same toys. – Tannic

Maven plus Groovy (GMaven) is the way to go. Rigidness and Flexibility! +1 – Mcgill

@Adam Gent - Why wouldn't you just use Gradle? Then you get the flexibility of Groovy, but without the big XML mess... – Referendum

@Chris Jaynes because you still need to make a POM file for distribution to the central maven repo. And from Maven you can call Gradle or (whatever is in vogue next) from Maven. IE Maven can do the bootstrapping of your build process. So open source developers don't need to go download another build tool (from maven you can also make sure they get the right version of gradle). – Mcgill

@Adam Gent - I admit I haven't messed around with it, yet, but Gradle is supposed to be able to generate POM files for publishing back to repos: gradle.org/maven_plugin.html. Having spent a bit of time with both tools, I can agree with you that embedding Groovy scripts in Maven works okay, but it is still not as elegant as being able to get Maven out of the way and do builds your way, instead of dancing around what Maven thinks you should be doing. Whether Gradle replaces Maven or not, I agree with Steven that Maven's rigidity will ultimately be its downfall... – Referendum

After working with Maven 3 for a year, this sums it up very nicely. Basically, if your build problems fall in line with how Maven believes you should be operating, you have a fine time. Once you do anything remotely intelligent or custom, it makes you pay for it with blood. I don't hate it but it's not as flexible as I believe it should be. – Omniumgatherum

@steven : great synopsis of why maven is broken by design. As some other ppl said : people who love maven, love its theory; people who hate maven, hate its reality ! – Malleolus

Answer 3

We use Maven here, but I find that once you get outside of a simple project, the pom.xml starts to get more and more complex. You start spending a lot of time working out how in the heck to configure your pom to do what you want, and how to work around the various issues.

The thing that really got me was the ear we're building. We have multiple wars in that ear file, and Maven normally sticks the libraries in the wars. However, to reduce the size of the wars, and to keep the jars all the same, we wanted to put the jars shared between the wars in the ear's lib directory.

Unfortunately, Maven doesn't handle this very well. We needed to manually configure this for each of the wars' poms, and then add all of these dependencies into the ear's pom.

In another project we have HTML based help files. The people who write the help write them in Microsoft Word then use a program to translate them into HTML. A single character change can reverberate throughout hundreds of files.

To get around this issue, our help system is stored in our source repository as a single zipped file. When our documentation team creates a new set of help files, they zip it up and replace what is in the repository.

So, part of my build is unzipping this file and placing it in the war. Easy to do in Ant, can't do it in Maven unless you use the Antrun plugin which allows you to write Ant code to handle issues that Maven cannot handle without a full blown plugin.

I can see what Maven is doing, but theory got ahead of reality. What I found is that Ivy and Ant can do most of the dependency checking that Maven does without all the issues of writing and maintaining the poms.

If you're not already using Maven, try Ant with Ivy first. Then when, Maven 3 comes out, try that. I remember the transition from Maven 1 to Maven 2. They were entirely incompatible with each other and anything you learned using Maven 1 was obsolete. It would be silly to learn and redo your projects in Maven 2 to suddenly find yourself redoing everything for Maven 3.

Forge

True, the EAR support with skinny WARs is painful in Maven 2.0. Regarding the transition to Maven 3, Maven 3.0 can be used as a drop-in replacement for Maven 2 and all the Maven 2.x projects I've tested build fine with Maven 3.0 (non backwards-compatible changes should happen in Maven 3.1). There is thus no possible comparison with the Maven 1 to Maven 2 transition. – Butene

You could use the dependency plugin to unpack that zip. – Analphabetic

If you're building your WAR using maven-assembly-plugin, you have an option to unpack a dependency (zip in your case) in the assembly descriptor. – Downtime

Answer 4

maven 3.x is already embedded in IDEs (at least on netbeans, check this link for more infomration). You can play today with maven 3.x simply building a Maven project with netbeans.

Another nice news is that maven got more 'enterprise' support with integrating EJB/WS in IDE projects (again, at least on netbeans).

So I would stick to maven 2.x for production builds and play with maven 3.x for development.

Trevatrevah

Great to know. Another plus for moving to Netbeans. Will check that out. Thanks. – Mill

fwiw: m2eclipse and maven3 are developed in parallel by Sonatype. – Untenable

Answer 5

Maven 2 and 3 have both been working perfectly for me on a variety of projects. I am currently using Maven 3 alpha 7 which works very well, especially in conjunction with the Eclipse Maven plugin.

Maven integrates seamlessly with Ant - in both directions. In my current project, we invoke Maven from Ant multiple times in order to perform complex integration test. Likewise, we use Ant via Maven's AntRun plugin, and we also wrote our own Maven plugins. This, by the way, is a matter of minutes and boils down to writing an annotated Pojo.

Maven gets a lot of flak because many developers don't like rules or conventions. Quite simply, nobody forces you to use Maven. If you want ultimate freedom - by any means - re-write your own build process for every project you join. However, if you like to create software rather than re-inventing the wheel with a custom-made build process on every project, go for Maven.

Pruter

You make it sound like a choice between Maven or reinventing the wheel but that's a huge fallacy. The Ant build file I use on projects today is almost identical to the one I was using 8 years ago. Its a wheel that just keeps on rolling. In contrast, Maven is a wheel that keeps on getting punctures. Its not because developers don't like conventions that they give Maven flak. They give it flak because occasionally they need to do things that are not conventional. – Rancidity

Answer 6

Keep your code well maintained and broken into well defined modules and porting between build systems becomes a minor problem.

As for now, maven-2 is a good choice for the middle 2/3rd of projects. For the really simple, ant is still ok. For the really complex, a hybrid of maven-2 and other tools (like antrun) becomes inevitable.

Not sure why you are having problems with maven-2.

It differs from ant and buildr in that it is a tool for describing your build process, not scripting it. Complex builds, the ones with multiple dynamic parts and nested and/or transient dependencies are hard to build because they are hard to describe.

Coaxial

Answer 7

Give Lattice https://github.com/hackingspirit/Lattice a try. I am the author. Here is the scoop:

In Lattice build files are written not in XML, but in the Python language. The ben- efits are much better readability and powerful imperative build scripting supported by Python. For multi-module projects. Lattice uses topological sorting to decide the correct order to build each module. It’s also planned that Lattice will analyze the module dependency to determine how the module compilation can be parallelized. Lattice’s source code is extremely lean, currently it consists of about 500 lines of Python source code.

Kurtz

Answer 8

I think people complaining about Maven should spend a little extra time investigating available plugins. In response to comments complaining that Maven is rigid and makes it hard to use custom build logic / provide fine-grained control over the build process - I would recommend looking into Ant plug-in for Maven (there are actually several, but here is one: http://maven.apache.org/plugins/maven-antrun-plugin). I have had great success customizing Maven builds with it over the years. Basically, it allows you to run any Ant command as part of the Maven build, and you can do pretty much anything with Ant ;)

Malloch

You shouldn't answer a question from 2009 just to complain about complainers. – Cording

Answer 9

Ant with Ivy does the same dependency management Maven does (in fact, it uses Maven's whole dependency management infrastructure including the same URL repositories), but without all the POM configuration mess.

Ant with Ivy might be a way of handling the dependency issues for people who really don't want to use Maven. It solves 90% of the stuff that Maven was suppose to solve.

Forge

Sure, build.xml are not a mess at all and are not a nightmare to maintain :) – Butene

Right, let me show you some of the Ant builds I've had to maintain over the past five years, then you can compare them to the equivalent pom.xml. Seriously?! – Analphabetic