gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: [RT]
Date Sun, 13 Apr 2003 19:26:00 GMT
Adam Jack wrote:
> 	I do envision all code to be in Python.  However the future I see most
> 	likely is that the code that does a build (for example) would neither
> 	directly access the original workspace definition nor would this be code
> 	generated.
> I agree a cache or database as a local working definition is valuable
> (especially as module definitions are more distributed). I like that you are
> thinking about batch and non-batch modes of operation, however I would like
> to discuss the latter somewhat. I'm not arguing against, I am just curious..
> If the premise of gump continues to be "the latest from CVS with everything
> updated, or with some locally installed packages" what is the purpose of a
> non-batch mode Gump? I suspect most folks in development will build a
> package in eclipse (or other IDE) against what packages they have. (I just
> don't see them wanting to have "the latest up to this minute" given the
> overhead of that.) As such -- is non-batch operation intended for gump
> config debugging, or for build debugging, or?
> Just curious & trying to see through other's eyes...

Here's how things look from *my* eyes.  I am a command line user.  My 
IDE is vim.  For the last two+ years, I have done *all* of my builds 
using Gump.  I'm less active on Apache projects at the moment, but most 
of last year I was an active developer on Apache Axis.  Before that I 
was active on a number of Jakarta projects including Ant and Tomcat.

The Gump profile gets from CVS the packages that I am interested in, and 
references locally installed packages for everything else.  Yes, I am 
interested in a lot of packages.  Others may have different lists. 
That's what profiles are for.

I won't contribute to, or depend upon, projects that Stefano would not 
consider "friends of Gump".

I do debug integration problems quite frequently by issuing a sequence 
of commands like "cvs update -D 2003/04/10" and "build cocoon".  If 
projects "normally" build, then I can quickly narrow down an individual 
commit in one project that would cause a unit test to fail in another 

That being said, I would love to see Gump be more Eclipse aware and vice 
versa.  I'm just starting talks with some of the Eclipse developers to 
see if I can help motivate this.  And I plan to start building more 
Eclipse projects using Gump.

> regards,
> Adam
> BTW: What comes to my mind is gump helping with "keeping the build
> environment up-to-date". Much as something like Ruper (or other) could keep
> built packages up-to-date, I see gump as managing (by building)
> dependencies.

If the project descriptors had download instructions for installed 
packages, Python has excellent HTTP support built in.

- Sam Ruby

View raw message