Building The Projects

The Ant Project keeps the projects working smoothly together. The build process uses the recommended-but-hated form of XML entities for including shared Ant XML fragments in each project. Future versions of Ant may include the <include> and <import> tags, which would simplify the current system. However, the build process works just fine without it, for the moment.

You can download the source from the downloads page.

If you are interested in building the projects from scratch, here's the recommended process:

Ensure you have JDK 1.2, JDK 1.3, and JDK 1.4 installed on your system. The complete build process will require all of these to be installed, but it is not needed for most circumstances. Also, to completely test the projects you will need to be connected to the internet while running the build, but again this is not needed for most circumstances, but is required for actual releases.
Download the latest CVS tree (see the Sourceforge project CVS page for details on how to do this). The module to download is 'projects'. The CVS tree will contain all the necessary non-JDK files needed for building.
Currently, only Windows, Unix-like variants, and Cygwin are supported build platforms. Windows users should use 'make.bat' from the base directory, while Cygwin and Unix-like users should use 'make.sh'. The remainder of this guide is oriented towards Bash shell users on Unix platforms, but other platforms and shells should be very similar. Alternatively, you can use the 'makeall.sh' script to build the entire project, which does about the following:

      $ cd 'projects' home
      $ export JAVA_HOME=JDK 1.4 home
      $ ./make.sh clean
      $ export JAVA_HOME=JDK 1.2 home
      $ ./make.sh main
      $ export JAVA_HOME=JDK 1.3 home
      $ ./make.sh main
      $ export JAVA_HOME=JDK 1.4 home
      $ ./make.sh deploy

By this time, you have just spent about 30 minutes to 5 hours building and testing all the sub-projects on all supported JDK versions. The final deployment output is sitting in the '_projects' sub-project 'deploy' directory. Each sub-project will have its individual deployment file set in its own 'deploy' directory.

Why Does CVS Contain Everything?

I have put everything in CVS that the build depends upon, except for the OS and JDKs. I, the build manager for GroboUtils had (and still has) responsiblities involving both source control repository (SCR) maintenance and build maintenance. If the developers have fewer dependencies that they have to locally manage, then they have fewer risks to cause the build to fail when everything works fine for them. Not only that, but by putting all dependencies in the SCR, it reduces the problem of the build manager dealing with "source rot" while trying to rediscover the exact library files that the source works with.

I've known some people who do go so far as to archive the OS and JDKs in the SCR, and rebuild from scratch the build machine every time. Now it's true that this allows the project to be able to completely restore a build based on just the SCR, and the build managers are less dependent on the IT group to correctly rebuild the machine in the case of critical failures, I feel that you still need the hardware the build was compiled on. If you don't have an OS for your hardware, then you're just as screwed as if you don't have the same hardware.

But this project, like most Java and open-source projects, are in a different boat. We want to be compiled on lots of hardware, OSs, and JDKs.

So what is this rambling about? It means that the SCR respository has been optimized to reduce third-party dependencies for the user, while opening the platforms available for compatibility testing.


This space graciously provided by the SourceForge project	Copyright © 2002-2003 GroboUtils Project. All rights reserved.