Apache Gump を何故書いたのか。

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.

そして、事実上全てのプロジェクトが自身のプロジェクトに固有の Apache Ant バージョンを必要としていたのです。

この事は、非常にストレスのたまることだと思いました。 この頃、Apache Ant や Apache Tomcat といったプロジェクトのアクティブな開発者であったため、 私は、これらのプロジェクトに対して改善をしたいと思いました：しかし、Apache Cocoon などのプロジェクトで作業する際、自分自身の作業の成果を使用する事を妨げられてしまいました。最終的に、私は、自分が望むように Classpath をセットアップする独自のスクリプトを書くことで、自分が望むものが得られるということに気づきました。

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.

それは例え 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.

オープンソースソフトウェアのヘビーユーザであったため、多くのそれを深いスタックに結合する際、JAR Hell が Adam Jackにとって不平・不満の種となりました。健全な再利用をサポートする情熱が生まれてきました。

Apache Gump はソフトウェアの再利用を新鮮で健全なものとし、JAR Hell を軽減してくれます。