forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: Forresbot WANTED
Date Wed, 27 Nov 2002 15:43:04 GMT
Sam Ruby wrote:

 > As Nicola Ken has said, profiles can be defined.  What I will
 > volunteer to do (if there is interest) is to get the full profile
 > running, which you can use as a starting point to narrow down as you
 > see fit.

I understand and greatly appreciate. My reluctancy is however based on 
a) the machine would be running out of breath during Gump runs (but who 
cares at 2AM GMT ;-), b) the bandwidth required to do all these 
non-documentation-related checkouts and commits and c) I don't see _who_ 
will then come in afterwards and narrow down profiles so that the 
machine isn't 'just another Gump instance', but a slimmed-down one for 
site generation and publication only. <sentence audience="anybody, but 
not Sam personally">If someone steps up and says he's willing to do this 
narrowing down, no problemo. I don't have time for this, nor the 
experience. And no chest-thumping please: only say you will if you 
really are going to do it.</sentence>

Also, the site-generation & publication cycle is already supported by
our own Forrestbot, which doesn't need several gigs, but can be tweaked
to just check out the src/documentation root of the 'subscribed'
projects. OK, no Javadoc, but we should work on that. Anyhow, I have
this idea that Javadoc is just another compilation artefact, generating
class files but rather HTML output, and as such hasn't much to do with
what Forrest currently does. Maybe Forrest should retrieve where a 
project stores its documentation out of its gump descriptor. Then again, 
I don't want to tie Forrest and Gump much together.

Let's be clear: I like Gump a lot, it does a tremendous job, but I don't
have access to free bandwidth and diskspace - I'm very much willing to
pay for those however, when there's some special value in it for the
projects I care most about: Cocoon and Forrest.

And while I understand Nicola's light pressure in convincing me to just
  relinquish this reluctancy, I think the ASF has better sized equipment
at its disposal, with proper Java support (nagoya), to go full monty and
use Forrest embedded/triggered by Gump on that machine. Also, I'm pretty
sure integrating Forrest with Gump would add to SoC breakage right now,
and is a bad means to a good end. Gump should do what it is aimed at,
i.e. crossbuilding HEADs, just as Forrest. And maybe something else
needs to be created for other tasks, like generating Javadocs, and 
assembling various project resources (docs, javadoc, unit test reports, 
etc) from various sources and publish them across efficient protocols to 
an integrated website.

So, where do we go from here?

<aside>What is Gump anyway?

The concept of overriding classpaths and crossbuilding project HEADs
against each other (awesome!), or just some cron-like shell script
engine into which we are going to stick each and every time-triggered
task. I doubt the latter will scale. And I doubt this is what you want. 
But I'm sure it will be used for that reason, not because of technology, 
but because of ease, political correctness, or the fact that 'it is 
already there'.</aside>

OK - my asbestos shorts...!

Steven Noels                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at    
stevenn at                stevenn at

View raw message