Adam R. B. Jack wrote:
Stefano wrote:
Here is the notes I took while installing Gumpy:
- gumpy.sh is not executable
Yup, I work on M$. Never did figure out how to set those on this platform (and never felt them worth setting on same ;-). Still, please feel free to fix it.
kewl.
That said, since gumpy.sh is typically called by cron, I typically prefix with /bin/bash to ensure no path issues.
Note: I think I need folks to recognize that gumpy.sh is NOT the main point of contact for Gump (yet I keep finding folks starting there). Are these script so invisible/unapproachable?
assuming that geeks will read docs is wishful thinking.
I had to run "gumpy", I saw a script called "gumpy.py" and I run that and it worked somewhat. There was no need to look around for other things.
http://wiki.apache.org/gump/GumpScripts http://wiki.apache.org/gump/GumpCommandLineOptions
Nicola started a 'gmp' wrapper to try to put a single point of human contact onto these things, and it works, but maybe needs some polish also.
may I suggest to call that unification wrapper "gumpy" and have a "--cron" option or something that makes it work like a cron job?
Hmm --- as soon as we migrate to SVN and deprecate traditional I'll work to re-do the site and mention some of this information.
I'm at OSCON, I'll force the infra@ guys to do it ;-)
- why provide and workspace are in different files?
The profile contains the list of modules/projects. The workspace is one's local configuration (locations on disk, etc.) One can share/re-use a profile (e.g. profile/gump.xml), one typically does not share a workspace.
gotcha (might be nice to have this information *inside* the documents as comments. again, people interested in gump are not the people that will read docs ;-)
- workspace "email|maillist" should be "to|from" since you might not want to send it to mail list but to yourself
Yup, agreed 100%. Since we started having a few remote Gumps, and since we don't have releases (every commit get's run) I was worried about element/attribute name changes. I once started a mail on metadata deprecation/migration (and how we do it in Gump) and this is what we need here. I'll try to get to that.
Gump is not a released official product and we have no back-compatibility plan for now (and there are not so many installations around). I think it's a better to cleanup things now than later.
- where do relative directories start from? [shouldn't there be a "basedir" attribute like for ant build files?]
- there is no -h|--help for gumpy
- the "-d|--debug" CLI parameter doesn't do anything
Not sure I follow this, 'cos they exist/do. That said, gumpy.sh is meant for cron -- so logs to a file, it isn't great to the screen [it tries to detect isatty but I don't think that works]. Is that the problem?
see above.
- the "workspace" configuration template should contain all the possible parameters that gumpy recognizes as comments
Good point.
- I think the "this runs the Python Gump" can go away now
Agreed. Done. :)
- running the minimal-profile.xml generates 15% of successes and 27% of failures and 57% of prereqs. *Not exactly promising*
- ant says "success" when the "bootstrap-ant" is a failure... *smells like severe problems here*
Do you have ant on your CLASSPATH?
no, I don't use classpaths, they are evil.
best I can think of. This really needs to be fixed:
http://nagoya.apache.org/jira/browse/GUMP-51
Any takers?
Overall experience: not so bad, but it *definately* needs polishing... it totally feels like a system that only one guy uses :-/ we'd better fix that.
Please. :)
I have thought about it *very* seriously and I will stick to Gumpy instead of rewriting my own version in Java.
but we need to cleanup the repository very fast because it's too messy.
I'll bug the infra@ people
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
