cwash into software

In terms of the sheer number of moving parts, extravagance, and complexity, the build-tool landscape is one of bells and whistles that can be a little tough to stay on top of. There are a few important pieces of a robust and valuable build, no matter what tools you use to achieve it, and by breaking the build into modules or categories, we can make a little bit of sense out of the chaos.

In our vast build-tool landscape, there tend to be some zealous cults out there, entrenched deeply in their own camps and unwilling to venture out to explore what the rest of the landscape has to offer.   Thus, there have been some religious-like differences of opinion about which build tools are better and why.  Sadly you run across these types of biases all too often, which only pollutes the landscape and makes it more difficult to wrap your head the most basic questions underlying all tools:

• What does it accomplish?
• When is it (or isn’t it) right for the job?
• How do I use it effectively and efficiently?

With a pragmatic view, we can try to cut through a lot of the BS and figure out if a tool is worth its weight in:

1. dependencies/design complexity.
2. ease of use/interface complexity.
3. architectural decisions/compromises that it brings to the table.

Does the tool get us to the goal of a single button build/deploy?  If the answer is yes, I’ll welcome it with open arms.  Does it add me a form of feedback or some kind of statistic that could be a kind of gauge on a dashboard?  Then I may be interested in it, but it’s not nearly as vital.

Here’s an outline of what I typically look to include in a project’s build before I am satisfied:

• Compile - Obviously your build script would be for naught if you didn’t include this piece.  There’s also something to be said about some dynamic/interpreted languages (that run on the JVM) taking the hit on this step and producing compiled versions.  The argument is akin to compiling your JSPs back in the day.
• Unit test suite - Another one of those no-brainers!  You’ll obviously want to integrate your ability to run a single test or test suite from a build tool quickly and easily.
• Test reports - Test reports are an important way of visualizing the health of your project and are usually the first place you’ll go when you see something wrong.  A must have.
• Transitive dependency management - This is one of those sticky subjects that people like to argue about religiously.  Really the important thing to note here is that a crucial part of keeping your build clean and manageable is figuring out how to represent and resolve transitive dependencies, or second-level dependencies.  If your code directly depends on a library, odds are that library has its own run-time dependencies that need to be satisified in order for it to work properly.  Since managing the different versions of many different libraries can become tough when you start to look at different “stacks” of software, many people advocate having a tool help you resolve these dependencies so it’s not as daunting a task to get the entire stack to work again when you need to upgrade a single library.  Maven and Ivy solve this problem by introducing repositories that will house and dynamically resolve these versioning issues, in much the same manner as yum or apt-get does in the Linux world.  A lot of newbs will make the mistake of thinking this type of functionality will let them turn off their brain when it comes to think about their project’s dependencies.  They will be sorely mistaken!  The point of these to make resolving conflicts in transitive dependencies easier, they do not replace your brain, nor your obligation to know the dependencies in your project and how they fit together!
• Utility ant tasks - the daunting part of learning how to write good builds has a bit to do with how much you know about the ant task landscape.  Nearly all libraries have tools that plug into ant, but which ones do you really need to know about?  I’ve found a few are quite powerful, particularly replace, uptodate, cvstagdiff (and corresponding svn’s), xmltask and dbdeploy.  I think these tools should be looked at when you are trying to figure out how to accomplish something specific, and for that reason, they’re a bit more like “bells and whistles” than anything else.  The same goes for the next category, which arguably doesn’t even need to live in your build (but if you’re a team player, it’s a definite nice to have):
• Static analysis - There have been a barage of slick static-analysis tools that have entered the Java landscape recently.  A few are FindBugs, PMD, CheckStyle.  While most of these tools have plugins that integrate nicely into an IDE, it’s also helpful to have them plugged into your build, too.  Just to make sure everyone is following the rules.  A few others I’ve seen that focus on cyclomatic complexity, cohesion/coupling are Metrics and JDepend.

What build tools fit into your pimped out script?