On Thu, 25 Mar 2004, Leo Simons <[EMAIL PROTECTED]> wrote: > Traditional gump has this architecture. > > On completion, some other script files are or can be run to do some > other things (like send out failure notifications).
which is done by a Perl script, which just adds to the tool mix of "traditional" Gump. > (Scripts are available to check things directly provided you have > console access to the server, but only a handful of people > (approximately 4 or 5 on the planet) know how to use them But note that if you know how to use them, debugging a Gump build becomes very effective and avoids the "wait 24 hours" part. We really need an equivalent of this in whatever Gump ends up to be in future iterations. Be it easier to use scripts on a server everybody has access to or be it via a build-on-demand webapp. > Replace this batch concept with a command/action/event > concept. I think we need both. We will always want to have some sort of "nightly Gump build" that ensures that all projects will be updated and built. In the end the batch concept can be emulated by pushing the command in via a batch job. > - Get rid of the "giant tree transformations". It has proven to > scale only with difficulty. If you separate the graph building from the commands, then submitting commands will need some help by the system. I wouldn't want to figure out which projects I have to build first when I say "update and build ant". The batch-like part I've talked about above will still need the full graph, but I agree that the full graph doesn't need to be - and maybe even shouldn't be - the core part of Gump. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
