5 Little Things I Want from a Build System

I have been thinking real hard lately what would the the top things I would look for in a build environment.

Granted I have had amble experience from early days and until now, which include very prehistoric makefiles and shell scripts up til the more modern equivalents. This includes ant, ant-ivy, maven-1, maven-2, as well as gradle and rake, and quite recently buildr.

I see a lot of people arguing over what is better, but more often than not I think these blogs tend to overlook the vital factors I would be looking for to provide some professionalism to the build, and to put it simple, it is not who has the biggest fastest build, the coolest syntax or the easiest extensibility, but a little more .... mature, I would say.

• Dependency management
• Build task materialization
• Include QA heuristics in your build
• Understand enterprise projects
• IDE integration

Dependency management

Software today face increasingly reuse. Especially with runtime models such as OSGi, it is vital that we modularize into smaller and more dedicated units. This sooner rather than later starts to provide you with a lot of dependency graphs, that essentially needs to be resolved. Now, I don't really care how it is specified, but the point being, that some software knows and publish their dependency requirements, and as such we can use automated dependency management, actually we should. Why have to do this stuff manually?? Maven dependencies was the first. Good or bad, they were there and with the right metadata in your poms, it actually gives you full dependency management. However, over the years I have become increasingly disappointed with the quality of the provided software (as in the examples here). It is also emerging in OSGi applications to have this full dependency resolution, however, there are quite a few catches in there as well.

Build task materialization

One thing I have always really admired Maven for (believe it or not) is the ability to materialize everything on demand. Mostly people see this for the project dependencies, but I see it particularly useful for the build plugins. As soon as you need some functionality in your build it is automatically downloaded to your box. I have always hated this part of ant. You need to download all the ant extensions manually, or sometimes the entire tools projects, get it configured through xmlns extensions etc, before usage. Needless to say it does make it harder to get started, unless you start storing all the libraries in some project folder, and hence in source control... With ant I sometimes use the get task to download things I need to configure, but the build scripts doesn't look nice and slick, and there is a limit to how good it will get. Another very terrifying example are the ant tasks, which eclipse provides for Eclipse RCP ant builds (and their very cumbersome recursive ant scripts). Essentially the only way to use them is to use the Eclipse Antrunner.. So far I have only met two guys, who actually understood how eclipse rcp builds really worked when running headless...

Include QA heuristics in your build

This is kind of an offspring of the previous. I really fancy to have plugin materialization, because I like to include some stuff that will ALWAYS be executed in the build. Especially have a build cycle, which can encompass what you really need in modern builds, code-generation, compilation (plus cross language compilation), packaging, but also UNIT TESTING, PMD REPORTS, FINDBUGS, CHECKSTYLE etc, all the modern day QA heuristics, so they are always integrated into the build. It is easy to put into the build, and then it IS IN THERE, not something that really need a lot of maintenance and extra downloads etc.

Understand enterprise projects

This is basically the evolutionary understanding that any slightly more advanced project than hello-world application today is multi-modular, and needs to be able to expand when modularisation becomes necessary (Not just expanding into a bigger project, but multiple smaller, less coupled ones), so it needs to be able to handle this without exploding in build complexity. Ant doesn't really scale to multi project builds. Maven have some mechanism for treating this in an independent fashion using modules and parents, but the rudimentary distance between a project and its parent have actually created more problems in my builds than it has ever solved. Also maintaining the set of pom files unfortunately reach a peak point after which you just don't want to flexibly refactor anymore.

Projects also needs to be a single independent file tree. Mostly, such that it can be located anywhere without much any configuration and still succeed first time. Especially on the new developers machine, on your new laptop, the spare you bring for the trip, or even the continuous integration server or any of its slaves. This is often automatically the case in open source projects because of their distributed nature, but I'm surprised how bad it still can be in certain enterprise companies. Wake up and smell the dawn of the millenium...

IDE Integration

With this I do not mean that you should have the ability to run or edit build scripts in an IDE. Clearly all IDEs allow you to edit files and execute some external application. No, it is more the very little thing that seems to escape me the most. Given that the build system has a lot of knowledge of your project nature, your dependencies and your intrinsic QA requirements (pmd ruleset etc), it should be possible to setup a consistent ide environment from the build. I don't really care if it is the IDE, that provides the integration or the build system (like the difference between using Eclipse's Maven plugin or Maven's eclipse plugin), but it needs to be understood in a consistent manner. It has always annoyed me that ant would have all these paths setup, but they needed to be duplicated in the IDE, because they were not consistently parseable.

In essence these are my requirements. With this I believe that I can tackle the finer hurdles of enterprise software. I need solid dependency management in a complex, multi project build with location transparency and preferable good IDE integration from a single build solution. That it would be fast, imperative, extensible and easy to maintain is just an added bonus.. What do you think?

My latest surprise in this respect has been my encounter with apache buildr. Even though I have not done much Ruby, and not really up for it, I must admit this encounter was a very positive experience. Could this potentially tip me off from recommending using Maven in the enterprise.