You are viewing a plain text version of this content. The canonical link for it is here.
Posted to alexandria-dev@jakarta.apache.org by ru...@apache.org on 2001/10/28 18:52:24 UTC
cvs commit: jakarta-alexandria/proposal/gump/site/xdocs why.xml
rubys 01/10/28 09:52:24
Added: proposal/gump/site/xdocs why.xml
Log:
Actually add the referenced document this time.
Revision Changes Path
1.1 jakarta-alexandria/proposal/gump/site/xdocs/why.xml
Index: why.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<author email="rubys@us.ibm.com">Sam Ruby</author>
<title>Gump</title>
</properties>
<body>
<section name="Why was Gump written?">
<p>
I've read with great amusement the motivations attributed to why Gump
was originally written. The reasons were most definitely not altruistic.
To understand why Gump was written, you need to understand a bit of
the history of the Jakarta and XML projects. But, first, here is a
concise and concrete summary:
</p>
<ul>
<li>It is easier to get a patch accepted against the most current version
of a project than some previous baseline.</li>
</ul>
<subsection name="1999">
<p>First you have to realize that at this time, 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.</p>
<p>In 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.</p>
<p>And virtually every project required their own specific version of
Ant.</p>
<p>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.</p>
</subsection>
<subsection name="2000">
<p>During this period, Ant got 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.</p>
<p>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.</p>
<p>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 and is 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.</p>
<p>But it was the only way I could regain control.</p>
</subsection>
<subsection name="2001">
<p>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
becomming 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.</p>
<p>The solution to my problems was to automate the generation of these
scripts and to publish the results.</p>
<p>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 never seen a clean
run. I could provide timely feedback on the impact of their changes on
others, and in turn help them make their case against changes that would
affect them.</p>
<p>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.</p>
</subsection>
<subsection name="2002">
<p>There is a growing trend for projects to split into multiple cvs trees -
Avalon, Tomcat, and Turbine are examples. Also 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.</p>
<p>I'd like to see Gump evolve into an developer tool. 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.</p>
<p>Perhaps even with a GUI.</p>
<p>With Ant becoming stable and backwards compatible, I'd 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.</p>
<p>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.</p>
</subsection>
</section>
</body>
</document>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>