Chapter II: Ranking each build tool based on 6 categories
In this chapter, we look at six areas in which an ideal build tool should really excel–from getting started and then maintaining your build process for the long term, plugins, community and documentation quality, we put each tool to the test and see how they do…
How easy is the initial learning curve?
When learning a new technology or tool, it’s always nice to get up and running really quickly making use of features that are both intuitive and easy to use.
So, we’ll look at how much advance knowledge is needed, how easy it is to script something up from scratch, debugging, minor customizations and problem solving. Two things: 1) the quality of the community and documentation (which is another section) plays a role here and 2) we are not considering the impact of long-term project maintainability in this section.
Learning Maven is not a hard thing to do and you don’t need to be familiar with Maven to be able to build and package the artifact or run unit tests on some existing project. Maven’s pom.xml file comes in to play here, and it’s harder creating a new file from scratch than just adding changes to an existing one–this is where your IDE comes in, as Eclipse, IntelliJ IDEA and NetBeans will all generate some minimal working pom.xml, where you will have to change artifact’s attributes and introduce some dependencies if you feel like it.
Of course the bigger the project becomes the bigger is its pom.xml file. Multi-module projects have several build files and suddenly you see that it becomes hard to trace all the links and dependencies among the pom.xml files. Refactoring them is a separate task: moving the configuration to parent or child pom, resolving version constraints and so on, these all can really drive you mad, but this isn’t a problem you should encounter too often.
Custom actions during the build is another challenge. As we mentioned in the previous report, Maven does not let you describe build steps right in pom.xml as the build script is used only to turn on or off some plugins/functionalities. So in order to add some custom logic to your build process, you actually have to use the Antrun plugin and write your logic in Ant’s build.xml or create your own plugin!
Nonetheless, the learning curve for Maven isn’t terrible and after a couple hours of reading in parallel with writing your build script, you’ll do enough trial and error to get started.
Creating a pom from scratch is difficult, but IDEs can do that for you. The inability to easily customize your build process (i.e. using Ant is needed) isn’t great, but getting started isn’t terribly difficult using the right docs.
The learning curve for Gradle is partially affected by another JVM language–Groovy. With just a little understanding of Groovy, it is really easy to get it working and understand it thoroughly, especially if you have a little background with Maven as well (as most devs do). But in reality, installing Gradle and getting it to work is also quite easy even without experience with these tools at all.
So how it is possible? Gradle actually has some things that make it easily adoptable and understandable to wide audience. For example, it’s based on Groovy, which is something like a simplified version of Java that is easily understandable for Java developers. Gradle also uses Maven’s (or Ivy’s) repository format, so that managing dependencies in Gradle does not require any extra learning time from you if you have experience with either of these tools.
The most time consuming part and what makes the learning curve a little bit more gentle is the Gradle DSL. It’s a totally new thing, introduced by Gradle itself and tightly connected to Gradle internals. But on the other side, Gradle DSL makes writing Gradle build scripts quite enjoyable because of lot of open possibilities.
Some experience with Maven or Ant + Ivy is useful. You have to learn a bit of Groovy, but that’s just syntax, as with anything. Gradle DSL is simple, intuitive and incredibly flexible–you can even start from an empty script and build from scratch.
ANT + IVY
Starting to learn Ant and Ivy isn’t the hardest task in the world, but previous experience with build tools, dependency management, and XML will go a long way. Getting a simple Ant script up and running doesn’t take long; there are plenty of templates that can be found around the web, and a lot of the IDEs out there can also auto-generate a basic Ant script for you.
Unfortunately, Ivy doesn’t have the same widespread IDE support as Ant, but templates do exist online. Of course, you can also follow the simple steps as described in the previous report to get started.
The hard part about Ant is often to maintain and expand your build script as your project grows in size and complexity. While Ant is pretty logically structured, it can be tricky at times to figure out which tasks and attributes to use, and how to use it! Most IDEs have full tag-completion for Ant scripts, but of course that doesn’t help much if looking for a task called compile, you really should be looking for a task called Javac instead.
Overall, for getting something simple up and running with both Ant and Ivy, the learning curve is fairly small. Yes, you have to get familiar with XML, and the basics tags, but once that’s done, you also have the template for future scripts.
Logical and simple to get started using good old XML, but understanding references to files can be painful, having to learn both Ant and Ivy syntax and maintain two files isn’t awesome.
DOWNLOAD THE PDF