I am looking to start a new project (web application in Java/J2EE using Spring). I am looking for build tools which are available. I have heard about Maven and Gradle, providing more features compared to Ant like
convention over configuration,
But still not able to find out the best tool that can be used. I have gone through lots of discussion, all are saying Gradle is better compared to Maven, but the articles were published in 2009, I have not found out the new article comparing the features of both Gradle and Maven.
Please suggest the best build tool.
I've been using Maven for several years in different enterprise projects and could recommend it to you. I do not have any experiences with Gradle, so could not tell you which one is better.
However I can assure you that if you choose Maven, you will not be disappointed. You can quickly configure your continuous build environment using Maven together with Nexus and Hudson.
All of them are great products easily installed and maintained.
There is also another nice feature of Maven: plugins written in Java. There are lot of thems: for example for managing dependencies, starting application server, sql operations.
If is not enough, you can always write your own plugin, which is easy and well documented.
And one more thing, as I can see on Gradle site, the last version is 1.0-milestone-3.
In case of Maven the last version is 3.03, You can also choose version 2.2.1 (I'm currently using it).
If you start a commercial project using stable version is a must IMO.
I hope this will help you making your decision
SCJP 5, SCWCD 1.4, SCBCD 5, SCEA part1
posted 8 years ago
Thanks for reply Pawel. I have heard that pom.xml becomes too complex if your project size is getting bigger, moreover you cannot go for scripting in pom.xml (which you may need at some time) and the maven is rigid. All these problems are addressed in Gradle which is groovy based.
Amit Arora<br />SCJP 1.4, SCWCD
posted 8 years ago
You can modularise your project with parent and child modules. Each module can be a parent for another modules as well. This way you don't have to put everything into single pom.xml.
Another approach is dividing your big project into smaller independent projects. Each of them producing its own artifacts (jar for example) placed in repository. Your main project becomes smaller and simpler, using artifacts already present in repository. Its not only a remedy for complex poms, but also for making your application easy to maintain. In case of Gradle build I would recommend similar approach.
Concerning scripting, do you really need it ? For typical tasks like unpacking dependencies or creating EARs, you can use plugins (http://maven.apache.org/plugins/index.html) . Which is simpler and more reliable then creating your own scripts. Or you can create his own plugin in Java, which give you more flexibility and control (JUnit tests for your plugins) then writing scripts.
However if you insist to write scripts in groovy, you can also do it, by using groovy-maven-plugin.
I wasn't aware of Gradle until this post, and I looked it up and it seems to me like it's Ant+Ivy in Groovy. It's great if Ant is your cup of tea
However, personally, after using Maven, I stay away from Ant as far as possible. Ant has tremendous flexibility over Maven, but IMO, that is a short coming of Ant.It's fine for small projects/one-man-two-man shop, but when you are trying to build multiple products with multiple modules each, Ant's flexibility tends to start working against it. There are too many things that you can do wrong with Ant, and generally, developers end up doing it wrong. The thing is doing things the "right way" in ant requires some thought. You need to start thinking about the "design" of your build scripts. However, in most teams where developers write build scripts, the build script is an afterthought. Developers are and should be focused on writing good production code, not on writing good build scripts
Maven, OTH, being rigid doesn't allow you to mess up as bad as Ant does. All your developers need to worry about is a) which plugin to use, b) which phase to bind the plugin to, c) which dependencies to add to the project. I think the only point where you need to be worried about in a large project is conflicting dependencies, and there are some good practices that you can follow.