Mailing-List: contact gump-help@jakarta.apache.org; run by ezmlm
Reply-To: <ajack@TrySybase.com>
From: "Adam Jack" <ajack@TrySybase.com>
To: <gump@jakarta.apache.org>
Subject: Gump suggestions
Date: Fri, 11 Apr 2003 18:01:33 -0600
Message-ID: <01ea01c30086$aefc8bf0$bb1ce641@wdn086>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal

All,

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

Documentation:

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:
	<A
HREF="http://ant.apache.org/manual/sysclasspath.html">build.sysclasspath</A>
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
Y".)
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 nag.pl? [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 nag.pl 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 nag.pl? Could it be added to the new gump.sh?
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
gump.sh 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...

regards

Adam
--
<http://www.try.sybase.com>
Experience Sybase Technology ...