forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <...@outerthought.org>
Subject RE: forrestbot for remote projects
Date Mon, 22 Jul 2002 15:25:08 GMT
After some more tweaking and tuning, ready for commit
(and while steven is getting out line-ending stuff...
 newsflash: Steven is waiting for the nikola commits to be
 leaving some consistent and not breaking setup again)

>
> 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.
>

coming, but there is more to clean up before it will actually work
see new mail threads: afraid we'ld like to clean up some to really get it
working
so maybe the CVS stuff helps thinking about one and the other
but there is some more 'general discussion' ideas we should check-off

> >>another filenaming issue: let's call this file 'forrestbot.xconf'
> >
> >
> > another +1
>
> -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.
>

I personally like the name.type.xml template for xml files.
It releaves the need to open the xml file to check the <!DOCTYPE...>
ant files become: *. build.xml, this one could become forrestbot.conf.xml


> > 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
>

we decided for build/bot


> >>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.
>

yep, saw that now, guess the mail-task should be the way to do it.
combined with the <try-catch> stuff probably to distinguish between succes
and failure


> >>>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)
> >>>

actually we're a bit stuck on the generation template (see
templates.build.xml)
feels like too much current hackery in prepare-docs needs to be copied over
to the template
quick hacks are fine, but my personal believe is that they always need to be
cleared out
before you start duplicating them all over :-)


> > 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)
>
>      <antipede-trycatch>
>       <try>
>          do things here...
>       </try>
>       <catch>
>         <echo message="Unable to ..." />
>       </catch>
>      </antipede-trycatch>
>

I did a small test, the <parallel> seems to be okay for thread indepence
the try-catch is great for sending the nag-mail though.

> > 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
> work.build.xml;
> > <target name="work">
> >   <parallel>
> >     <antcall target="work.my-project" />
> >     <!-- 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> ?

yep. (note: the commit that is coming took the new approach expressed here
above)
to enhance your understanding: get a look at what the new target 'bot.run'
is doing

basically we decided that the remote generation of a documentation site has
5 distinct stages
1. prepare: creating dirs
2. get-src: getting the source in some configured way
3. generate: actuall do the commandline cocoon
4. deploy: copy the generated stuff to where-ever the config tells us to
5. cleanup: no idea yet, but it looked nice and symmetrical :-)


>
> > 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...
>

the way I see this:
get-src stage could be configured to get multiple stuff into the same
directory?

snippet of forrestbot.xconf:
<project name="bundled-site">
	<get-src type="cvs">
		<module name="xml-forrest" />
	</get-src>
	<get-src type="cvs">
		<module name="xml-cocoon" />
      </get-src>
	<deploy type="scp" />
</property>

but do we really need it?
this sounds like one site could be generated from xdoc sources retrieved and
assembled from two distinct cvs sources?

what benefits would it offer over
<project name="bundled-site">
	<get-src type="cvs">
		<module name="xml-forrest" />
	</get-src>
	<deploy type="cvs">
		<modules name="xml-site/target/forrest" />
	</deploy>
</project>
<project name="cocoon-section">
	<get-src type="cvs">
		<module name="xml-cocoon" />
      </get-src>
	<deploy type="cvs">
		<modules name="xml-site/target/cocoon" />
	</deploy>
</project>

but maybe you were thinking of something else

-marc=


Mime
View raw message