Wednesday, May 18, 2005

Build Environment Systems

When ever you start a new project you'll find out, that you have to ship the software at a certain point :-) and to do that there are many tasks involved:
  • deliver the application as a zip file including a batch or shell script to execute it
  • deliver the application with all the necessary deployment descriptors, security role assignments, etc., so the application can be deployed
  • deliver an installer for one or many operating systems
  • deliver it in any kind your customer would like to have it
Usually this task is not that complex, but there are many tiny tasks involved, like:
  • pack all the necessary libs for your application
  • generate a working classpath (sometimes not that easy...)
  • generate all the documentations
  • generate the batch and shell scripts
  • generate some testdata
  • create the installer build files
  • etc.
If you forget one or you don't do them the same way every time, your delivery won't address the needs and the expectations of your customer.

Beside this, if your delivery will be tested by some testing folks on the customer side, they'll flood your bug tracking system, because some bugs will look quite different every time. And you won't hire some new people just to sort out the same bugs, would you? ;-)

To address these needs, most Java projects are using Ant. Ant is a quasi standard for building Java applications. The Apache Ant project describes itself as: Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.

In Ant you can define targets and within the targets you have different tasks. The targets once more can have dependencies to other targets. If you are not familiar with Ant, have a look at "Writing a Simple Buildfile" tutorial from the Ant project. This will give you a good introduction.

If you start using Ant, you figure out, that you are doing the same things again and again. For example: your application is based on several components and you would like to compile each of them independently. You'll start writing a compile target for every component and at a certain point you'll try to refactor your build files so you can use one compile target for all your components.

I invested quite some time in my build files and started to use them in different projects. So I started to use my own build environment components. I'm not quite sure, if this is the right approache, since there are many projects out there which are doing the same thing... but usually much more sophisticated...

These projects are using Ant or extending it and building a set of predefined targets to use:
To get a more complete list of Ant related tools, check the Ant project site:
Another Apache project, addressing the need of a good build environment system is Maven. Maven itself is much more sophisticated than Ant and they use a different aproach. Maven is built around a project object model and is providing a huge set of goals (in Ant terms these would be targets). Beside this, Maven is able to deal with dependencies in your project.

Currently the Maven team is working on Version 2.0 of Maven. If you are interested in Maven 2.0 have a look at the project site: http://maven.apache.org/maven2/.

It's very much recommended, that you invest enough time in your build environment and that you maintain it as good as possible. You should keep in mind, that your build scripts are a part of your software and you should treat it with the same respect as your source code.

Some people might think, that a fully automated build environment is to expensive. But if you have a closer look at all the details and all the knowledge lying in your build environment and in your build process, you'll see that the positive aspects outweigh.

To understand the importance of a good build environment, you also should read the article of Martin Fowler about Continuous Integration.

No comments: