[[ 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
