forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: [Proposal] forrestbot at apache.org
Date Tue, 01 Feb 2005 03:35:51 GMT
Dave Brondsema wrote:
> David Crossley wrote:
> >Dave Brondsema wrote:
> >>David Crossley wrote:
> >>
> >>>I suddenly realised the issue with "cocoon-trunk". It needs
> >>>to run its 'build docs' before running 'forrest'. It generates
> >>>some extra source documentation before forrest starts.
> >>>
> >>>There is a global parameter "forrest-exec" which can call
> >>>a shell script to do other things, then call forrest.
> >>
> >>A better option would be to have the forrestbot buildfile for 
> >>cocoon-trunk run its 'build docs', then you don't affect any other 
> >>projects.
> >
> >That is okay, my forrest-exec shell wrapper has a case statement
> >to switch based on siteName to handle various special "pre-forrest"
> >operations. However, the length of time that it takes, causes
> >the issue that i mention below - forrestbot run via the webapp
> >will not know if there is a forrestbot already running via
> >cron and vice versa. I think that can be fixed in my wrapper
> >by checking/setting the date on the cocoon-trunk forrestbot log.
> 
> Hmm.. perhaps this should be added to forrest[bot] itself.  Not sure how..

Yes, i had already thought of that too. I was wondering if 
when forrestbot starts we can create a flag file in the
forrestbot-logs directory, which gets removed at the end
of the process. I have started a coding experiment.
We would probably also need a way to check if there was
a stale flag file lying around.

> >Anyway, thanks, it is good to know that the forrestbot buildfile
> >has that capability - du'oh i should have realised that.
> >Perhaps i can move some of the pre-forrest functionality.
> 
> And if you do so then other people can use the same buildfile without 
> needing the shell wrapper.

Yes, the more in there the better.

> >Youch, just tried it. I presume that you mean adding an <import>
> >for the cocoon-trunk/build.xml then calling the forrestbot
> >with targets "docs" and then "build". I get errors from cocoon's
> >"docs" target because forrestbot is not running in the top-level
> >of cocoon's source.
> 
> Maybe using the 'ant' task would work better; with it you can specify 
> the buildfile and directory.

I will try that in my next free time.

> >Also, because forrestbot only does 'svn up' for the exact parts
> >of the sources that it requires, i need to do an 'svn up'
> >for the full cocoon-trunk. This needs to happen over in the
> >work/svn/cocoon-trunk space, then do cocoon's 'build docs' there,
> >then let forrestbot copy the sources to its ${build.work-dir}
> 
> Hmm, I don't know enough about cocoon's build procedure.  Perhaps the 
> cocoon buildfile should provide it's own 'getsrc' implementation (which 
> would depend on getsrc.svn and then do more complete updates).

I am afraid to add even more to the cocoon build procedure.
It is already so complex. But yes, that might be a solution.

> >>>I have the forrestbot working now for cocoon-trunk.
> >>>There is potential to have multiple cocoon-trunk builds
> >>>running, so i am currently finding a way to avoid that.
> >>>
> >>>--David

Mime
View raw message