You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Peter Janes <pe...@liberate.com> on 2004/10/08 08:59:37 UTC

Re: maven, gump, developer effort

Leo Simons wrote:
> I will assert that the most serious concern with gump is that it is too 
> hard to use, understand or improve for non-gump-gurus. If this were a 
> componay and I were the boss, the first thing I would tell people to 
> work on is a much more readable and enticing website. Ie "What is Gump? 
> Gump is a social experiment." is not very successful marketing-wise.

For what it's worth, I don't think it's too hard to use or understand.

(Times below are approximate because I've been doing this as a side project 
for work whenever I've had a few free cycles.)

I had my very first experience setting up "classic" XSLT Gump just before it 
was removed from CVS, based only on the "GOM" docs on the website and the 
existing metadata files.  Within a couple of days I'd extended it to perform 
Perforce-based checkouts.  I used a half-dozen of the "official" metadata 
modules but the vast majority are homegrown.

Migrating the classic install to Python Gump, sans Perforce support, was a 
snap.  Adding Perforce took a little while longer--about a week--but that was 
mostly due to my unfamiliarity with Python and the structure of the code.

There are certainly things to be improved, most of which are being discussed 
in other threads right now.  Of greatest importance (to me, at least) are 
reporting and nagging, both of which are pretty heavyweight: the classic 
versions were much friendlier.  It would also be nice to achieve parity with 
classic Gump, specifically supporting the <javadoc/> element.  The internals 
aren't the easiest thing to dive into to make changes, or I'd probably have 
added support for publishing Javadocs to the artifacts repository myself.

All in all, I don't think Gump for "users" is as horrendous a beast as you've 
made it sound.  I don't consider myself a "gump-guru" in any sense, but I've 
had more trouble getting Ant to run some of our less trivial builds than I had 
installing, configuring and running Gump to build the 60-odd projects we have 
in-house.  I don't understand Maven *at all*, and I've tried a couple of times.

> The second thing I would have my team do is to get in place a 
> double-click (and/or configure; make; make install) installer.

Which would do what exactly, other than unzip the distribution into a 
directory?  I'm just curious--other than getting SVN, Java and the right 
version of Python onto a new machine, it took me all of 5 minutes to 
completely "reinstall" my entire Gump setup, so I don't understand why an 
installer would be worth the effort.  (Unless you're talking about rolling out 
Gump to every person on a team... in which case my question would be "why?")

Peter J.
-- 
Sometimes the Universe needs a change of perspective.
   --J. Michael Straczynski

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org