forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Forresbot WANTED
Date Wed, 27 Nov 2002 23:40:04 GMT

Steven Noels wrote:
> Nicola Ken Barozzi wrote:
>> But there is a shortcoming: some projects need to create artifacts 
>> prior to doc generation: currently the Forrestbot cannot do it, while 
>> Gump can.
>> Also there is an issue about delivering the site and the usage of 
>> resources: using Forrest in Gump runs for Apache projects makes this 
>> scenario all easier to set up.
> Easier?
> Do you mean Gump will do Javadoc generation?

It does.

> Or unit test runs? 

It does.

> And 
> which distribution methods does Gump currently offer, apart for what it 
> needs for its own results (result web pages and nag emails), in 
> comparison with Forrest?

> Forrest is currently able to use cvs, local copy, scp and possibly other 
> Ant tasks as delivery methods. So given the proper runtime environment, 
> it is capable of doing most of what is needed for project site 
> generation and publishing. Forrest's scope _IS_ site generation.
> Now if we need Javadoc, we can add it to the Forrest generation process. 
> But still, I think we might be mixing the concerns between a lot of 
> different functions:
>  * cross-building HEAD CVS trees
>  * building nice websites from a collection of xml documents
>  * aggregating & filtering Apache HTTPD usage stats
>  * running unit tests
>  * syntax-higlighting entire source trees
>  * ... other future niftyness
> Should all of this be done by one system? Nope.

Steven *who said that* ?!?!
I want to be able to publish Gump results with Forrest and Forrest sites 
with Gump, who talked about *one* system?

> You were the guy who came up with Vindico IIRC. So why should we now 
> jump to Gump instead of designing a proper solution? Because Gump is 
> there and Gump works? Yes - but it will only work as long as it is used 
> for what it has been designed for.

Vindico was meant to be Gump2. I don't understand what you say here.

> Maybe we are trying to put too many functions in one entity. Maybe some 
> superservice (cron) should exist which triggers Ant scripts which drive 
> the functions listed above. Or shell scripts if Ant doesn't quite cut 
> it. Maybe Forrest is just a service for such an ├╝berserver. But thinking 
> Gump is that superserver, or might organically evolve into one, I'm not 
> sure.
>> Now, there always has been an overlap between Gump and Forrest.
>> Gump builds projects with the latest and greatest code, and can 
>> publish artifacts of this. It's reasonable that Forrest can be used to 
>> create some of these artifacts (documentation).
> I violently disagree that documentation is an artefact of code. 

Violently? Come on, what's this, a fight?!?

Artefacts of code are part of the documentation.
I want javadocs, code docs, unit test results, checkstyle reports and 
*whatever* the build wants to give me to be part of the documentation, 
part of the site.

> Javadoc 
> is. Documentation has a separate concern, aim, goal, life cycle, etc... 
> Why is there an HTTPD Documentation Project? Because it didn't quite fit 
> into the normal repository / way of working, I guess... Why is it that 
> the idea of having a separate CVS module for Cocoon docs has often been 
> mentioned already? And now the Wiki kind-of fullfills that role somehow?


>> On the other hand Forrestbot builds sites, but cannot include easily 
>> artifacts from project compilation (some kind of catch22).
>> Here are some things to consider (all non-exclusive):
>> 1) Enhance Forrestbot by making a tag that enables it to run build 
>> targets and scripts prior to doc generation. This will create the 
>> extra stuff we need. In this way Forrestbot becomes a nightly build 
>> system, and the forrest build becomes just one of the possible things 
>> that are run on that code.
> +1, for a selected number of tasks (Javadoc _might_ be an option)
> As of currently, not many people took a thorough look into the existing 
> Forrestbot, I guess. Let's try to build on what we have, instead of 
> jumping into yet another direction.


>> 2) Enhance Forrest by making it able to mount resources from urls, so 
>> that systems like Gump can publish the artifacts in Forrest format 
>> somewhere and have the forrestbot pick them up.
> +0.5
>> 3) Simply make projects that are Gumped use Forrest as a site 
>> generation system and be able to publish the sites from the Gump run. 
>> These runs differ from the Forrestbot ones because they are done 
>> without forcing the latest code in compilation.
> -1
>> 4) Make Gump build its site with Forrest instead of Anakia; this will 
>> keep Gump artifacts separate but still skinned by Forrest. The 
>> Forrestbot remains the same and publishes only the bare site.
> don't see the point in this

Look at the Gump site at least once, and at the Alexandria site. Maybe 
you'll understand what I mean. I want it to be a Forrestized site.

>> Comments, suggestions, etc.
> Sorry ;-)

not funny

All this stuff and you left out:

"Forrestbot has its place as a standalone publishing bot, and it will 
never need Gump to do it. Also for many cases Gump is overkill to setup 
and use. This means that Forrestbot it has its place and that it will be 
supported and used."

I cannot get my message through to you, I don't know why.

It seems to me that you are being overly defensive, and I'm getting 
tired of these discussions. I'll continue them on the Gump and Centipede 

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message