forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: forrestbot for remote projects
Date Sun, 21 Jul 2002 19:26:11 GMT

Marc Portier wrote:
> goes without saying (I presumed):
> I just added my own build.xml file to be able to kickstart the process for
> now...
> I'm kind of expecting the current ruling ant-wiz-kid to step in, comment,
> and maybe give some pointers/ideas on which project-wide props to use...
> Nikola?

Put in CVS, make me see it working, then we'll work on it.
Discussing is ok for general ideas, but when coding takes place, I wanna 
have it CVS.

>>>I hope the attached files do a better job in explaining what I
>>try to say
>>>in short,
>>>0. in forrest cvs will be build.xml and
>>>1. if you want to setup a forrest-bot, you need to make a config.xml
>>another filenaming issue: let's call this file 'forrestbot.xconf'
> another +1


I have removed all the .xconf stuff from the general descriptors because 
editors usually are associated with .xml.
Let's stick with *.xml files.

> while we're at it, probably build/forrestbot makes more sense then
> build/work as a working dir?

As long as it runs you can call it make/it/work :-P

>>>2. running 'forrestbot' target in build.xml should build
>> and
>>> .xml from config.xml
>>>3. build.xml should then delegate to which in
>>turn delegates
>>Where will we be setting that Mail logger/listener I was referring to in
>>my previous post? We need to configure that one, too, with a
>>project-specific email address to nag... hopefully those settings aren't
>>  globally set.
> My guess would be in the shell that does the 'ant forrestbot'

Nags can be sent with a special email logger per ant buildfile or with 
the mail task.

>>>Steven volunteered on creating the needed xslt
>>>already working on it, hence my questions ;-)
>>>I could (and like to) do some of the template stuff (but that
>>should be an
>>>ongoing task as more get-src and deploy types will be required)
>>>before we all run off doing this, any more
>>People, we are well aware of the fact that part of the discussion that
>>led to this proposal wasn't done on the list, but in our (Outerthought)
>>offices instead. We try to summarize as much as possible on the list,
>>but of course this doesn't fully reflect the discussion held around our
>>whiteboard. If you have any remark or suggestion with regards to this
>>process, please feel absolutely free to say so. We don't want the
>>community to be alienated by the fact that Marc and I have much more
>>communication bandwidth available than through email exchanges only.

Then share the code right away.
As long as it compiles, commit commit commit.

Don't do the same error you did with libre, commit, man.

> this made me rethink carefully our discussions and try to
> list other things we've been talking about:
> 1. resilience
> --> how to make sure that an error in one of the projects to build doesn't
> prevent the others to build?
> is using <parallel> in ant enough to achieve that?

use the try-catch task that Centipede gives you (see ant-contrib try-catch)

         do things here...
        <echo message="Unable to ..." />

> 2. grouping
> --> should we process either (1) workstage by workstage all projects
> (current approach)
>     or rather (2) project by project all workstages?
> (probably better considering the resilience question...
>  projects shouldn't block each other, but workstages should, no?)
> this would easily be achieved by following modifications to;
> <target name="work">
>   <parallel>
>     <antcall target="" />
>     <!-- antcall target="${stage}.all-other-projects"  -->
>   </parallel>
> </target>
> and then have some
> <target name="work.[for-each-project]"
>         depends="cleanup.[for-each-project]" />
> and in each
> <target name="[worstage].[for-each-project]"
>         depends="[previous-workstage].[for-each-project]" >
> 	<!-- same as now -->
> </target>
> what I still dislike (previous approach had the same)
> is that the knowledge of the workstages (which ones and their order) is
> inside the config2work.xsl
> maybe we should split that off in some <workstages> tag into the
> forrestbot.xconf
> other ideas on this?

Could you please expand on the term <workstages> ?

> 3. multi-project sites (with maybe xrefs)
> --> there should be one <project> entry in the forrestbot.xconf per set of
> html pages you want to create. If that would be based on more then one
> project source, then you should be able to add just multiple <get-src>
> elements in there
> --> remaining issue is how to tell these separate projects that a certain
> other project is locally available and thus that cross refs could be made
> local?
> (probably over the top, at least for now?)

Not over the top, it's important...
...still thinking...

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

View raw message