To help set the context, in 1999 the ink was hardly dry on the XML specifications; and what is now known as XSLT, FOP, and XPath were all interwoven in a confused jumble. JDK 1.2 was only recently introduced and wouldn't be widely adopted for many years (to this day, a number of projects retain JDK 1.1 compatibility).

In this harsh environment, it is amazing that open source software grew at all. In order to make progress, early versions of Xalan required specific versions of Xerces. Cocoon required specific versions of both. Cocoon also depended on other projects which were two years away from having alpha releases - Turbine and Avalon.

And virtually every project required their own specific version of Ant.

I found this time very frustrating. As an active developer at the time on projects such as Ant and Tomcat, I wanted to make improvements to these projects; but was precluded from using the fruits of my own labors when working with projects like cocoon. Ultimately, I found that I could get what I wanted by writing my own scripts to set up the classpath as I wanted.

In 2000, Ant developed the ability to control one's classpath. This completely defeated my ability to select which versions I wanted to use. At first, this was done on projects I wasn't active in, but eventually it encroached everywhere.

Then one day a change was checked in that completely broke me. As an active committer on the project, I "-1'ed" the change. That -1 was declared invalid, shouted down, and ignored.

So I did the only thing I could think of. I hacked Ant so that I could tell it to ignore the classpath elements in build scripts. All of them. This was then and remains now a dirty, nasty hack. It meant that test cases could not be run using the recently compiled classes unless I knew in advance where the classes were to be placed. It means that cactus can't be built in one run against both Tomcat 3 and Tomcat 4.

But it was the only way I could regain control.

Now that I had a technological solution to my problems, the number of projects I was interested in following grew. This resulted in a number of problems of scalability: the first being that the scripts were becoming more difficult to maintain, and second that the long chains of dependencies were fragile and only worked if the participants were interested in supporting the combination of projects that I wanted to run.

The solution to my problems was to automate the generation of these scripts and to publish the results.

The results exceeded my expectations. People who claimed that version incompatibility problems were rare and easily addressed could now see that it was a daily event - in fact to this day, I have only seen a clean run a mere handful of times. But what I could provide to developers was timely feedback on the impact of their changes on others, and in turn help them make their case against changes that would affect them.

Most telling of all were the changes to three projects: Ant, Turbine, and Avalon. All three were notorious for making changes which broke their users. In the cases of Turbine and Avalon, these projects were perennially in alpha, so it was argued that nobody should depend on them. Now, there are stable releases of each. Deprecation is now actively used by all three.

There is a growing trend for projects to split into multiple cvs trees - Avalon, Tomcat, and Turbine are examples. The creation of "commons" areas shared between projects makes it more and more likely that other developers are interested in multiple code bases and face some of the same problems that I have faced.

For these reasons, I'd like to see Gump evolve into an developer tool. The overall concept is as follows: one describes using simple XML constructs the combination of projects and versions thereof that one desires in their workspace, and customized scripts are built to order. The results of one's builds are conveniently published as HTML.

Perhaps even with a GUI.

With Ant becoming stable and backwards compatible, I'd also like to see a movement towards it becoming something that you install and occasionally upgrade, as opposed to something that you download with each and every project.

Now that XML parsers and XSL translators are pluggable and default versions will be shipping with the JDK, it would also be nice if each project stopped shipping duplicate copies of these jars too, and instead used the one of your choosing.

As a heavy user of OSS software, combining lots of it into deep stacks, JAR Hell became a pet peave of Adam Jack. Supporting heathly re-use became a passion.

Gump keeps software re-use fresh and healthy and reduces JAR Hell.