gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [RT] gump.py
Date Mon, 14 Apr 2003 14:34:14 GMT
Sam Ruby wrote:
> The only significant 
> difference between the way Gump runs and the way developer do builds 
> should be the value of the build.sysclasspath property, and this is 
> something that can be set and experimented with outside of Gump.

note: I would assert that's only valid for ant (-style) builds. With the 
configure/make/make test style build, I would imagine having to define a 
complete configure script (like building httpd with apxs).

> Key issues with the current Gump implementation are its reliance on DOM, 
> XSLT, and generated BAT/bash scripts.  These choices represent barriers 
> to entry for potential contributors to the Gump codebase.  They also 
> make it more difficult to implement appropriate error recovery and 
> provide meaningful error messages when the inevitable configuration 
> errors occur.

+100. I'm a javahead, so I can read jenny's code once and get it. I've 
been over the xslt sheets and what comes out of them a few dozen times 
and it just still fails to make any sense.

> The current implementation [2] has four basic parts.

I'll have a look at that. My python skills are rusty tho' :D

> Next, we need to figure out how to handle external project definitions. 

some options:

1 - get them via http from a project's home on the web
2 - get them via cvs from a project's version control module
3 - get them from some kind of central database or repository

additional choices:

a - cache the results
b - don't cache the results

IMHO simply the best one is (2a), since it keeps metadata closest to 
what it applies to and the caching is automatic as you have to do the 
cvs checkout already anyway. The downside is the cirkle of people who 
can maintain project definitions shrinks due to cvs access restrictions. 
So you use a repository stored in cvs and updated through the same 
mechanism, make the location of the project definitions configurable, 
done. In particular, the code which updates/caches definitions can be 
particularly simple as you can reuse existing cvs libraries.

IOW, the krysalis project definitions are in cvs, so they are already 
available, cached, on the local disk. I imagine

<project
	href="file:///${gump.cvsbase}/krysalis-charts/gump.xml"
	type="centipede"/>
<project
	href="file:///${gump.cvsbase}/jakarta-struts/gump.xml"
	type="ant"/>
<project
	href="file:///${gump.cvsbase}/jakarta-turbine-3/project.xml"
	type="maven"/>

> The speed of this script would degrade significantly if these were read 
> every time.  Either some sort of caching which is only explicitly 
> updated based upon request is needed, or a serialization of the full 
> merged definition (like to the current Jenny logic does) is required.

or you need to keep the merged thing in memory, ie run a daemon process. 
I am guessing the work neccessary to write a persistent service is a lot 
more tho'.

> Finally, the logic current placed in XSLT stylesheets would need to be 
> accomondated.

my guess is that a combination of python+template processor makes that 
quite easy.

> I'm only interested in pursuing this if it increases the development and 
> user community.

my python skills are rusty, but an order of magnitude bigger than my 
XSLT skills. I am kinda guessing that this is true for most of the 
world. (How many people have ever generated a bash script from XSLT? I 
think not many.) I also resonate with Stefano's comments on broader 
scope and python as truely free and mostly neutral ground.

cheers!

- Leo



Mime
View raw message