The concept is excellent.
The problem is that you don't run Gump locally.
These discussions amuse me.
I run Gump locally. Once a week or so (when things look good) I resynch by doing an overnight build. If things look bad, I go longer. But after that point I build and update individual projects on an individual and as needed basis.
Gump's implementation is in two parts: data reduction and generation. Despite years of feature creep, the data reduction is 7 Java classes. The generation is 13 stylesheets. Certainly, technology other than XSLT could have been used. These stylesheets generate two flavors of artifacts today: bash and win bat files. Additional flavors could be added (costin, for example, created an ant flavor).
One thing that I particularly like is that Gump itself doesn't require anything more than a current JDK to run.
Gump need not build using only inputs from cvs. It can use installed packages or even jars from cvs. The project definitions need not be centralized, they can be distributed.
Centipede and/or Ruper can eliminate much of the conceptual start up costs.
Recommended profiles of installed packages and/or related projects to build from cvs would address the rest.
- Sam Ruby
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
