gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <>
Subject Gump suggestions
Date Sat, 12 Apr 2003 00:01:33 GMT

Even newbies (seeing through fresh eyes) can have some valid feedback. Even
if it is probably old news to most experts, it might contain the odd random
nugget. As somebody who has (with some gump-inflicted, some self-inflicted,
pain & lots of grunting noise) set up a local gump, here is mine ...


1) Gump needs a either a "deeper" FAQ or a OIAQ
(Obscure-Infrequently-Asked-Questions). Example <depend ... remove="true" />
that does not appear to be documented. Gump is simple in essence & is
documented simply. It needs to be more completely documented.
2) A "verbosity" page would be excellent, e.g. "gump found property
"build.sysclasspath" with value="last" in workspace "xxx" to override all
project definitions. e.g. g. <depend inherit="xxx" so ... importing..
Doing so to HTML would seem excellent. One per workspace and one per
module/project would be fantastic.
3) An "annotated verbosity" page would be fantastic -- i.e. the above with
annotations like:
4) Gump needs to add documentation for "gen check" & "inadvisable usage" to
site documentation.

Gump is a black box:

Debugging the batch files is at times necessary, but it is tricky/awkward:

1) Generate separate batch files per project (and call) with sections and
sections comments (i.e. to assist with the user jumping to a section "where
the CLASSPATH is set for project X" or "the ant command line for project
2) Ability to generate the update/build batch files w/o HTML content (easier
to read when debugging)
3) 'echo' batch files and/or aspects (per project) to an HTML page (for
easier review).
4) Ability to set "-debug" (to pass to ant, not -Ddebug=true) via
module.xml, to debug ant from inside gump. [Sometimes it matters w/ messed
up environments.]
5) Project  'annotation' page this could be 3 above, or it could be "seeing
this in this project so ...." at the "build" or "update" level.

Gump w/ Nagging:

Do many folks use [Heck how many people use gump?] I suspect as the
latter grows the former will...

1) Nag need to be made portable to w2k (to anything w/o a
/usr/sbin/sendmail). This could be done w/ portal perl and SMTP, or
Javamail, or ... [ I don't know Python..]
2) Oughtn't the nag subject line be "host specific"? Meaning, a gump in my
environment might fail on a project for environmental reasons (bad package
install, whatever) but the nag e-mails generated from do not
discriminate between the main gump, and localized ones. Could nag
3) What about nag for dropped projects? I know it exists for the main gump,
does it work off the same Could it be added to the new
4) Ought not the name/e-mail address that gump from be
gump@`hostname --fqdn` rather than a person extracted from module.xml? When
two people gump the same project in two separate environments it seems wrong
that the nag e-mails do not identify which is from where. Environments (w/
packages) do affect the outcome - -so should be reflected. [Hmm, if no nag
in module.xml perhaps this could be the behaviour.]

Gump Usage & Debugging:

1) A dump of the resultant merge tree -- to an xml file would be
interesting. [It would have helped me when I incorrectly included on project
locally, but it was also in the result of an HTTP get, and I was scratching
my head trying to understand...]

2) Gump "suggestions" or "warning". Could it no say "Do not do xxxxx" if it
sees something it doesn't approve of? Maybe a warnings page. [BTW: The really ought output to an HTML page, but maybe that is too much
batch file hacking at the egg stage before the chicken arrives.]

3) Ought Gump provide simple module templates? At least for guidelines. They
could be kept current w/ changes from 'jakarta-ant' to 'ant' and nice hints
like use ant w/ inherit=runtime. This plus a simple build.xml ...

4) Gump ought allow *profiles* to be extracted from a URL. This is so both
profiles (as well as projects) it can be remotely managed in a CVS location
& accessed via viewcvs.cgi w/o it having to reside at jakarta-gump for local
gumps and folks like me who aren't committers. Hmm, haven't tried it -- I
wonder if it does.

This is my tuppence from using Gump, and wanting to see more people be able
to use it. I hope it is at least worth the read...

BTW: If any of this makes sense and/or is appealing I'd be willing to help
out as best I can. I must admit -- not that I know Python, but if the Python
suggeston is for gneration, or both generation time and runtime, I'd be
interested. A batch file (although proven doable) seems so crude compared to
what should be easily done w/ any OO scripting language...


Experience Sybase Technology ...

View raw message