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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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

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.

Answer 6

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