You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Marc Portier <mp...@outerthought.org> on 2002/07/25 18:29:23 UTC
[patch][wip] partial work done on templates.build.xml
should be able to get more finished tonight (off-line though)
but since the current bundle seems to work partially (and not break previous
stuff)...
would appreciate if someone could apply the patch
- changes to build.xml
- are not on existing stuff yet (although there could be some renaming and
repositioning done, xuse me)
- are in the bot-section: some new targets
- changes to forrestbot.conf.xml
- I realized that in current way of working the skin decision is
in the prepare step (not the generate)
- changes to layout.xml reflecting some dir jugling in build/bot still not
really comfortable, but hey, shoot me
- changes to templates.build.xml is where the functional reasoning for all
this hastle is, the rest is there to support that.
non self explaining things maybe:
- when doing a cvs get-src there is 2 distinct cvs actions:
1. to get the actual deep dir that holds the xdocs
2. to get only the module top dir (non recursive):
we need it for the project description *.*ml files
- also after the cvs actions files are locally copied to the context dir, I
have some dream of forrestbot maybe holding a cache of the cvsmodules he's
regulary updating (delta's rather then full checkouts?) so the cache would
be kept, and the context dir swept clean on each run of the bot?
- I'm not putting in the WEB-INF/classes in each distinct project,
instead I choose to share one among all central builds
(seems to work, please comment)
- there is no filter @token@-translations on stuff in documentation dirs
(see other discussion today)
upcoming work (more wip)
- provide deploy templates
(scp and local copy are on the list, others?)
- provide template for local-copy get-src
- refactor build.xml to use the defaults
- double-check the todo's just about everywhere around
oh, as for what is already done:
after patching go for > build clean bot
and find the forrest docs inside ./build/bot/xml-forrest/docs
in all cases I'm happy to get some feedback
hope you will be happy to receive more patches in the near future
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org info@outerthought.org
Re: [patch][wip] partial work done on templates.build.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> Steven Noels wrote:
>
>>>> I'll check tomorrow if this problem is solved using the JISP store
>>>
>
> done - problem solved :-)
>
> anyone opinions on defaulting to JispStore for holding cache files? I'll
> commit the jar and add Jisp configuration to
> src/resources/conf/cocoon.xconf.
+1
I had reverted to the filestore because of speed.
Put Jisp back in now, it's time :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [patch][wip] partial work done on templates.build.xml
Posted by Steven Noels <st...@outerthought.org>.
Steven Noels wrote:
>>> I'll check tomorrow if this problem is solved using the JISP store
done - problem solved :-)
anyone opinions on defaulting to JispStore for holding cache files? I'll
commit the jar and add Jisp configuration to
src/resources/conf/cocoon.xconf.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Re: [patch][wip] partial work done on templates.build.xml
Posted by Steven Noels <st...@outerthought.org>.
Marc Portier wrote:
>> getting links: .ERROR 2002-07-25 21:10:51.124 [core.sto] (): Error
>> storing object on fs
>> java.io.FileNotFoundException:
>> (The filename or extension is too long)
>>
>>I'll check tomorrow if this problem is solved using the JISP store (I
>>was thinking this was the already default for Forrest - has this changed
>>and who did so?)
>>
>
>
> do you get it also on the build docs is my main concern?
> a bit worried about the shared /WEB-INF/ still although I see no reason why
> it shouldn't work
nope :-|
I don't see this happening upon build docs
difference of course is that the cache files of the bot are created some
levels deeper down the fs hierarchy than the ordinary docs build,
hitting some hard limitation maybe...:
/cygwin/home/stevenn/projects/xml-forrest/build/bot/projects/xml-forrest/work/cache-dir/PCK%3ACCK%3A1%21content-aggregator%21%20-%20CA\(%3Asite%3C%3E\)P%3Dfalse%3Acocoon%3A%2F%2Fxml-site%2Fbook-xml-site%2Fdecisions%2E/
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
RE: [patch][wip] partial work done on templates.build.xml
Posted by Marc Portier <mp...@outerthought.org>.
> > should be able to get more finished tonight (off-line though)
> > but since the current bundle seems to work partially (and not
> break previous
> > stuff)...
>
> release early & often, they said ;-)
>
trying, it is taking some time to get it consistent
(not mentioning the time in learning to understand the current build
process)
> > would appreciate if someone could apply the patch
>
> done
>
thx
> > - changes to build.xml
> > - are not on existing stuff yet (although there could be some
> renaming and
> > repositioning done, xuse me)
>
> no problems encountered, your local build must have been reasonably up
> to date or the patch tool is smarter than we assume :-)
>
euh, I did an update and local merge, plus extra test just before the
diff -u of course
<snip />
> > - also after the cvs actions files are locally copied to the
> context dir, I
> > have some dream of forrestbot maybe holding a cache of the
> cvsmodules he's
> > regulary updating (delta's rather then full checkouts?) so the
> cache would
> > be kept, and the context dir swept clean on each run of the bot?
>
> we can keep the cvs check-outs for that purpose, no? when you do an
> update/checkout afterwards, only the changed files are updated
>
that's the idea, only I should change the dirnames for that
now it is .../cvsmodules/[projectname]/[modulename]
and I think .../cvsmodules/[hostname]/[modulename]/[branchname]
would be better for this purpose?
which reminds me: todo for checking out based on branch
> > - I'm not putting in the WEB-INF/classes in each distinct project,
> > instead I choose to share one among all central builds
> > (seems to work, please comment)
> > - there is no filter @token@-translations on stuff in documentation dirs
> > (see other discussion today)
> >
> > upcoming work (more wip)
> > - provide deploy templates
> > (scp and local copy are on the list, others?)
>
> cvs put - although setup will be much more complicated if at all
> possible ... but currently it is the de-facto standard for updating
> Apache websites (not that we should stick with the past - but we will
> have to seriously motivate why we are dropping this method)
of course, thx for reminding.
issue on the password though, can we assume that there will be a .cvspass?
>
> > - provide template for local-copy get-src
done by now, fun to see the <parallel> in ant work on two separate projects
now...
xml-forrest and xml-forrest-local
> > - refactor build.xml to use the defaults
> > - double-check the todo's just about everywhere around
> >
> > oh, as for what is already done:
> > after patching go for > build clean bot
> > and find the forrest docs inside ./build/bot/xml-forrest/docs
>
> it does work, except for some image errors, and loads of cache write
> errors due to excessive lengthy filenames:
>
> getting links: .ERROR 2002-07-25 21:10:51.124 [core.sto] (): Error
> storing object on fs
> java.io.FileNotFoundException:
> ..\work\cache-dir\PCK%3ACCK%3A1file%20-%20file%3A%2FC%3A%2Fcygwin%2Fh
> ome%2Fstevenn%2Fprojects%2Fxml-forrest%2Fbuild%2Fbot%2Fprojects%2F
> xml-forres\t%2Fcontext%2F%2E%2Fcon
> tent%2Fxdocs%2Fbook%2Exml%3ACCK%3A3xslt%20-%20file%3A%2FC%3A%2Fcyg
> win%2Fhome%2Fstevenn%2Fprojects%2F
> xml\-forrest%2Fbuild%2Fbot%2Fprojects%2Fxml-forrest%2Fcontext%2F%2
> E%2Fskins%2Fbert%2Fxslt%2Fhtml%2Fb
> ook2menu%2Exsl%3Bisfaq%3D%3Bre\source%3Dtodo%2Ehtml%3ACCK%3A3xslt%
> 20-%20file%3A%2FC%3A%2Fcygwin%2Fho
> me%2Fstevenn%2Fprojects%2Fxml-forrest%2Fbuild%2Fbot%2Fpro\jects%2F
> xml-forrest%2Fcontext%2F%2E%2Flibr
> ary%2Fxslt%2Ffilterlinks%2Exsl (The filename or extension is too long)
>
> I'll check tomorrow if this problem is solved using the JISP store (I
> was thinking this was the already default for Forrest - has this changed
> and who did so?)
>
do you get it also on the build docs is my main concern?
a bit worried about the shared /WEB-INF/ still although I see no reason why
it shouldn't work
untill the next,
-marc=
Re: [patch][wip] partial work done on templates.build.xml
Posted by Steven Noels <st...@outerthought.org>.
Marc Portier wrote:
> should be able to get more finished tonight (off-line though)
> but since the current bundle seems to work partially (and not break previous
> stuff)...
release early & often, they said ;-)
> would appreciate if someone could apply the patch
done
> - changes to build.xml
> - are not on existing stuff yet (although there could be some renaming and
> repositioning done, xuse me)
no problems encountered, your local build must have been reasonably up
to date or the patch tool is smarter than we assume :-)
> - are in the bot-section: some new targets
> - changes to forrestbot.conf.xml
> - I realized that in current way of working the skin decision is
> in the prepare step (not the generate)
> - changes to layout.xml reflecting some dir jugling in build/bot still not
> really comfortable, but hey, shoot me
> - changes to templates.build.xml is where the functional reasoning for all
> this hastle is, the rest is there to support that.
>
>
> non self explaining things maybe:
> - when doing a cvs get-src there is 2 distinct cvs actions:
> 1. to get the actual deep dir that holds the xdocs
> 2. to get only the module top dir (non recursive):
> we need it for the project description *.*ml files
> - also after the cvs actions files are locally copied to the context dir, I
> have some dream of forrestbot maybe holding a cache of the cvsmodules he's
> regulary updating (delta's rather then full checkouts?) so the cache would
> be kept, and the context dir swept clean on each run of the bot?
we can keep the cvs check-outs for that purpose, no? when you do an
update/checkout afterwards, only the changed files are updated
> - I'm not putting in the WEB-INF/classes in each distinct project,
> instead I choose to share one among all central builds
> (seems to work, please comment)
> - there is no filter @token@-translations on stuff in documentation dirs
> (see other discussion today)
>
> upcoming work (more wip)
> - provide deploy templates
> (scp and local copy are on the list, others?)
cvs put - although setup will be much more complicated if at all
possible ... but currently it is the de-facto standard for updating
Apache websites (not that we should stick with the past - but we will
have to seriously motivate why we are dropping this method)
> - provide template for local-copy get-src
> - refactor build.xml to use the defaults
> - double-check the todo's just about everywhere around
>
> oh, as for what is already done:
> after patching go for > build clean bot
> and find the forrest docs inside ./build/bot/xml-forrest/docs
it does work, except for some image errors, and loads of cache write
errors due to excessive lengthy filenames:
getting links: .ERROR 2002-07-25 21:10:51.124 [core.sto] (): Error
storing object on fs
java.io.FileNotFoundException:
..\work\cache-dir\PCK%3ACCK%3A1file%20-%20file%3A%2FC%3A%2Fcygwin%2Fh
ome%2Fstevenn%2Fprojects%2Fxml-forrest%2Fbuild%2Fbot%2Fprojects%2Fxml-forres\t%2Fcontext%2F%2E%2Fcon
tent%2Fxdocs%2Fbook%2Exml%3ACCK%3A3xslt%20-%20file%3A%2FC%3A%2Fcygwin%2Fhome%2Fstevenn%2Fprojects%2F
xml\-forrest%2Fbuild%2Fbot%2Fprojects%2Fxml-forrest%2Fcontext%2F%2E%2Fskins%2Fbert%2Fxslt%2Fhtml%2Fb
ook2menu%2Exsl%3Bisfaq%3D%3Bre\source%3Dtodo%2Ehtml%3ACCK%3A3xslt%20-%20file%3A%2FC%3A%2Fcygwin%2Fho
me%2Fstevenn%2Fprojects%2Fxml-forrest%2Fbuild%2Fbot%2Fpro\jects%2Fxml-forrest%2Fcontext%2F%2E%2Flibr
ary%2Fxslt%2Ffilterlinks%2Exsl (The filename or extension is too long)
I'll check tomorrow if this problem is solved using the JISP store (I
was thinking this was the already default for Forrest - has this changed
and who did so?)
> in all cases I'm happy to get some feedback
(applause)
> hope you will be happy to receive more patches in the near future
lol :-)
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
Re: [VOTE ] Marc Portier as Forrest committer
Posted by David Crossley <cr...@indexgeo.com.au>.
Nicola Ken Barozzi wrote:
>
> Marc has done a neat job on the remote site build stuff, and works well
> with the Forrest community.
>
> He has clearly said that he will contribute even more in Forrest, since
> he is actively using it.
>
> I think he's able of committing his stuff by himself, don't you guys think?
>
> +1
Definitely ... +1 from me.
Thanks Ken, you beat me to it. I was in the process doing that,
but had email troubles over the weekend.
Welcome to Marc.
--David
Re: [VOTE ] Marc Portier as Forrest committer
Posted by Brian Behlendorf <br...@collab.net>.
Account created, password sent, commit privs granted.
Brian
On Fri, 26 Jul 2002, Steven Noels wrote:
> Nicola Ken Barozzi wrote:
>
> > Marc has done a neat job on the remote site build stuff, and works well
> > with the Forrest community.
> >
> > He has clearly said that he will contribute even more in Forrest, since
> > he is actively using it.
> >
> > I think he's able of committing his stuff by himself, don't you guys think?
> >
> > +1
>
> Courtesy +1 vote, since Marc already has three and the other side of the
> planet is fast asleep right now and was planning to propose Marc, too,
> which would bring us to 5 anyhow. It feels kind of good asking for
> commit privileges for a dear friend and colleague without actually
> proposing him myself - welcome aboard, Marc :-D
>
> ====================================================================
> Root/Brian/...:
>
> another Forrest committer coming along:
>
> name: Marc (first) Portier (last)
> username: mpo
> email: mpo@outerthought.org
> avail: xml-forrest|xml-site
>
> Vote tabulation:
>
> * [NKB] nicolaken@apache.org [+1]
> * [DC] crossley@apache.org [ ]
> * [SM] stefano@apache.org [ ]
> * [JM] morrijr@apache.org [+1]
> * [SN] stevenn@apache.org [+1]
> * [KP] kpiroumian@apache.org [+1]
> * [SR] rubys@apache.org [ ]
> * [BK] bert@apache.org [ ]
>
> could you please set up the account and grant privs?
> ====================================================================
>
> </Steven>
>
Re: [VOTE ] Marc Portier as Forrest committer
Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:
> Marc has done a neat job on the remote site build stuff, and works well
> with the Forrest community.
>
> He has clearly said that he will contribute even more in Forrest, since
> he is actively using it.
>
> I think he's able of committing his stuff by himself, don't you guys think?
>
> +1
Courtesy +1 vote, since Marc already has three and the other side of the
planet is fast asleep right now and was planning to propose Marc, too,
which would bring us to 5 anyhow. It feels kind of good asking for
commit privileges for a dear friend and colleague without actually
proposing him myself - welcome aboard, Marc :-D
====================================================================
Root/Brian/...:
another Forrest committer coming along:
name: Marc (first) Portier (last)
username: mpo
email: mpo@outerthought.org
avail: xml-forrest|xml-site
Vote tabulation:
* [NKB] nicolaken@apache.org [+1]
* [DC] crossley@apache.org [ ]
* [SM] stefano@apache.org [ ]
* [JM] morrijr@apache.org [+1]
* [SN] stevenn@apache.org [+1]
* [KP] kpiroumian@apache.org [+1]
* [SR] rubys@apache.org [ ]
* [BK] bert@apache.org [ ]
could you please set up the account and grant privs?
====================================================================
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
RE: [VOTE ] Marc Portier as Forrest committer
Posted by John Morrison <jo...@ntlworld.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >>Marc Portier wrote:
> ...
> >>>upcoming work (more wip)
> >>>- provide deploy.cvs template
> >>>- refactor build.xml to use the _templates_
> >>>- write a document on TheContract for people to use forrest
> >>> (not like the primer explaining, more a checklist, Bert can maybe
> >>> incorporate in his effort?)
>
> Marc has done a neat job on the remote site build stuff, and works well
> with the Forrest community.
>
> He has clearly said that he will contribute even more in Forrest, since
> he is actively using it.
>
> I think he's able of committing his stuff by himself, don't you
> guys think?
>
> +1
+1 - welcome Marc
J.
Re: [VOTE ] Marc Portier as Forrest committer
Posted by Bert Van Kets <be...@vankets.com>.
At 14:46 26/07/2002 +0200, you wrote:
> >>Marc Portier wrote:
>...
>>>>upcoming work (more wip)
>>>>- provide deploy.cvs template
>>>>- refactor build.xml to use the _templates_
>>>>- write a document on TheContract for people to use forrest
>>>> (not like the primer explaining, more a checklist, Bert can maybe
>>>> incorporate in his effort?)
>
>Marc has done a neat job on the remote site build stuff, and works well
>with the Forrest community.
>
>He has clearly said that he will contribute even more in Forrest, since he
>is actively using it.
>
>I think he's able of committing his stuff by himself, don't you guys think?
>
>+1
A bit too late (busy Friday and weekend) but a very big welcome to Mark
+1
Bert
>--
>Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
>---------------------------------------------------------------------
[VOTE ] Marc Portier as Forrest committer
Posted by Nicola Ken Barozzi <ni...@apache.org>.
>>Marc Portier wrote:
...
>>>upcoming work (more wip)
>>>- provide deploy.cvs template
>>>- refactor build.xml to use the _templates_
>>>- write a document on TheContract for people to use forrest
>>> (not like the primer explaining, more a checklist, Bert can maybe
>>> incorporate in his effort?)
Marc has done a neat job on the remote site build stuff, and works well
with the Forrest community.
He has clearly said that he will contribute even more in Forrest, since
he is actively using it.
I think he's able of committing his stuff by himself, don't you guys think?
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [patch][wip] more partial work done on templates.build.xml
Posted by Marc Portier <mp...@outerthought.org>.
> > could someone check if that is OK?
>
> will do & report back to the list
>
thx
<bigger-snip/>
> > questions:
> > - for the log: we're now delegating to work.projectname by
> using <antcall>
> > (since it is in the same file)... I'ld like to change that to
> <ant> so I
> > can dump the log via the @output.
> > See no reason why it shouldn't work. A sendlog will just send the log
> > to wherever the forrestbot.conf.xml is saying (any ideas on
> where to put
> > it
> > there, I was thinking @sendlogto on the <project>
>
> fair enough - will sending logs will only be for failed builds?
>
both should be feasible, same address will do?
could be future extension to have some [announce] workstage that fits
in after the cleanup?
<announce type="mail">
...
</announce>
sending the build log through however will require a target that sits
outside the normal workstaging thing
> > - as stated above: can someone check the scp stuff
>
> as stated above: I will :-)
>
> > - who and why would consider it usefull that one configured <project>
> > would have more then one <get-src> and more then one <deploy>
>
> more urgently perhaps: supporting project-owned skins? otherwise, we
> will have to check-in our outerthought skin in Forrest CVS ;-)
>
this is about extending the contract blokes!
point is the contract now says:
- project should provide: xdocs documentation in a dir they specify
- project can provide: project descriptor *.*ml files in the root
if you want the project to provide it's own skin (makes all the sense)
then maybe this is a more justified approach (also relieves some
<filter> stuff>
- we modify the sitemap to always work with .../skins/theskin/
(in stead of .../skins/@skin@/)
- the prepare stage copies the selected skin directory to there
(bert skin if no selection)
- the project can provide his own skin directory in a directory of
choice (communicated to the forrestbot.conf)
if it is available then the get-src stage will overwrite the
forrest default
deal?
we could have similar approaches for
- position of subsitemaps
- location for additional dtd's to move over (plus catalog?)
- need for own cocoon components (java src code and libs)
we can take them one at a time?
> <snip/>
>
> > which reminds me: todo for checking out based on branch
>
> yep, a cocoon requirement
>
duly noted
> > upcoming work (more wip)
> > - provide deploy.cvs template
> > - refactor build.xml to use the _templates_
> > - write a document on TheContract for people to use forrest
> > (not like the primer explaining, more a checklist, Bert can maybe
> > incorporate in his effort?)
>
> I'll see what I can contribute... I'm currently postponing announcement
> on general@xml.apache.org until we have forrestbot v0.1 finished and
> some docs written up - Bert, what is your schedule on this?
>
see above 'contract' mentioning to get a feel of what I mean
<snip-the-rest />
pick up earlier posting if you want to comment
-marc=
Re: [patch][wip] more partial work done on templates.build.xml
Posted by Steven Noels <st...@outerthought.org>.
Marc Portier wrote:
> hoping to finalize this evening, in the mean time there is another quick and
> early to look at
>
> mainly because I currently don't have the setup for the deploy.scp testing
> (which is copying what nicola and steven have setup for the forrest on
> krysalis)
> could someone check if that is OK?
will do & report back to the list
<snip/>
>
> the new stuff then:
> - local get-src and deploy
> - deploy scp
> - testing on 2 parallel projects (fun to see the <parallel> of ant work so
> well
> - check yourself with build clean bot
>
>
> questions:
> - for the log: we're now delegating to work.projectname by using <antcall>
> (since it is in the same file)... I'ld like to change that to <ant> so I
> can dump the log via the @output.
> See no reason why it shouldn't work. A sendlog will just send the log
> to wherever the forrestbot.conf.xml is saying (any ideas on where to put
> it
> there, I was thinking @sendlogto on the <project>
fair enough - will sending logs will only be for failed builds?
> - as stated above: can someone check the scp stuff
as stated above: I will :-)
> - who and why would consider it usefull that one configured <project>
> would have more then one <get-src> and more then one <deploy>
more urgently perhaps: supporting project-owned skins? otherwise, we
will have to check-in our outerthought skin in Forrest CVS ;-)
<snip/>
> which reminds me: todo for checking out based on branch
yep, a cocoon requirement
> upcoming work (more wip)
> - provide deploy.cvs template
> - refactor build.xml to use the _templates_
> - write a document on TheContract for people to use forrest
> (not like the primer explaining, more a checklist, Bert can maybe
> incorporate in his effort?)
I'll see what I can contribute... I'm currently postponing announcement
on general@xml.apache.org until we have forrestbot v0.1 finished and
some docs written up - Bert, what is your schedule on this?
> - double-check the todo's just about everywhere around
> - check on the 'clean' requirement david posted in another thread.
> - more comments in the config2work.xsl needed
> - check on cvs checkout based on branch
> - check on cvs checkout cache
>
>
> dream future:
> - Ian's discussion on other DTD's might be opened up to 'extending the
> contract'
See my following mail - we'll have to do some Cocoon coding for this
> Looking at the build process now: I hope we could snap in new or extend
> existing
> workstage-templates easily to gain in flexibility while retaining the ease
> of use
nice work, Marc
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org stevenn@apache.org
[patch][wip] more partial work done on templates.build.xml
Posted by Marc Portier <mp...@outerthought.org>.
hoping to finalize this evening, in the mean time there is another quick and
early to look at
mainly because I currently don't have the setup for the deploy.scp testing
(which is copying what nicola and steven have setup for the forrest on
krysalis)
could someone check if that is OK?
changes:
- in build.xml
I started thinking about the generation of logs, not finished yet though
- in forrestbot.conf.xml
added second project to test the local stuff (seems to work)
- templates.build.xml
the work in progress...
- config2work.xsl
is carrying the non change after reverting back the attempt for logs
the new stuff then:
- local get-src and deploy
- deploy scp
- testing on 2 parallel projects (fun to see the <parallel> of ant work so
well
- check yourself with build clean bot
questions:
- for the log: we're now delegating to work.projectname by using <antcall>
(since it is in the same file)... I'ld like to change that to <ant> so I
can dump the log via the @output.
See no reason why it shouldn't work. A sendlog will just send the log
to wherever the forrestbot.conf.xml is saying (any ideas on where to put
it
there, I was thinking @sendlogto on the <project>
- as stated above: can someone check the scp stuff
- who and why would consider it usefull that one configured <project>
would have more then one <get-src> and more then one <deploy>
- still thinking about the cvs checkout cache... more comments?
<snip>
> > have some dream of forrestbot maybe holding a cache of the
> cvsmodules he's
> > regulary updating (delta's rather then full checkouts?) so the
> cache would
> > be kept, and the context dir swept clean on each run of the bot?
>
> we can keep the cvs check-outs for that purpose, no? when you do an
> update/checkout afterwards, only the changed files are updated
>
that's the idea, only I should change the dirnames for that
now it is .../cvsmodules/[projectname]/[modulename]
and I think .../cvsmodules/[hostname]/[modulename]/[branchname]
would be better for this purpose?
which reminds me: todo for checking out based on branch
</snip>
upcoming work (more wip)
- provide deploy.cvs template
- refactor build.xml to use the _templates_
- write a document on TheContract for people to use forrest
(not like the primer explaining, more a checklist, Bert can maybe
incorporate in his effort?)
- double-check the todo's just about everywhere around
- check on the 'clean' requirement david posted in another thread.
- more comments in the config2work.xsl needed
- check on cvs checkout based on branch
- check on cvs checkout cache
dream future:
- Ian's discussion on other DTD's might be opened up to 'extending the
contract'
Looking at the build process now: I hope we could snap in new or extend
existing
workstage-templates easily to gain in flexibility while retaining the ease
of use