Re: gumpy

[Sam Ruby <ru...@us.ibm.com>]

[[ I'm choosing to respond to a private e-mail publically ]]

Geir Magnusson Jr. wrote:
>
> > http://elf.theochem.kth.se/~pawsa/ForrestGump.html
>
> But this points to a question that I have about Gump,
> namely, what's the point to use in this manner?
>
> I mean, I think its a great tool and all, but the cross dependency
> that gump seems to create in this nightly check is artifical in
> that there seems to be an implicit assumption that the current
> CVS of project A is fair game to try to use at any moment in
> project B that uses it.

It would be nice if the next release of Turbine works not only with the
previous release of Velocity, but also (as near as humanly possible) the
next one.

Example 1: Avalon added a "release" method to an interface.  This broke a
class in James which implemented that method.  Adding a null release method
to James neatly addressed the problem without introducing a dependency on
the next version.

Example 2: Turbine depended on an interface that log4j removed.  Once this
was identified, log4j added the interface back and deprecated it, agreeing
that it would be present (albeit deprecated) in the next release, and then
removed in the following one.

Frequent testing of this nature also helps in other ways.  I'm sure that
jvz would have found and fixed the problem that was identified over the
weekend himself, but having the symptoms and a test case made available
within hours of the change - while it was still fresh in his memory -
coupled with the knowledge that the test worked prior to the change should
have made this easy to address.

> If we add a new feature to Velocity, Turbine isn't broken if turbine
> includes a Velocity jar into its project, right?  It is up to the
> Turbiners to make the decision to get a new version of Vel, test it,
> and include in their project.
>
> In Velocity, we use JDOM, Xerces, et al : we prefer to simply take the
> a version or snapshot, test it, and include it.  Then we are confident
> that it will work for our users.

Turbine builds upon multiple components.  If Velocity only works against
Xerces 1_2_1, and some other component that Turbine requires only works
against Xerces 1_2_3, then composing a system with the four components is
not possible.

Cocoon has faced this problem (specifically with xerces) on a number of
occasions.

> I know you don't like binaries in CVS, but I disagree for exactly this
> reason - there is no other way to rely on software components if you
> can't control what version you use.

If you are a top level component, you arguably can have considerable say
into what versions your customers use.  If your component is designed to be
embeddable, then you must be prepared to give up much of that control.

Many of my objections to checking in binaries are addressed by my obtaining
a cable modem and by gump.  Actually, to be more precise, what I object to
is mixing editable files with derived files, and the amount of my objection
is inversely proportional to the "distance" between the two.  A cvs
repository which contained only jars which were certified to work together
would be a peachy idea.  Because the cvs "HEAD" revision of most open
source projects is fluid, one doesn't quite get this level of confidence
with jars mixed with source.  And jakarta-alexandria's practice of checking
in generated code was simply an accident waiting to happen.  Jakarta-site's
practice of checking in generated html is close to this extreme, but
thankfully there the consequences of failure aren't as dire.

In any case, because many projects check in binaries, the path of "working
against the previous version" is well tested.  I'm just trying to trying to
give the "next release" equal time.

My reason for providing the link to "shit happens" is that I don't get
upset about individual failures.  As long as more good comes out of this
than bad, we all benefit.

And I am quite willing to be patient.  It takes time to overcome the
objection "but this is the way I have always done it".

- Sam Ruby