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, 15 Jul 2002 07:37:48 GMT
As I was just telling Steven during morning coffee :-)


Steven Noels [mailto:stevenn@outerthought.org] wrote:
> Marc Portier wrote:
>
> > this mail proposes a step-by-step approach to implement the
> remote building
> > process.
> > input to that process would be something like >> attached config.xml
> > (looks like a proposal posted on list earlier, slightly
> modified to line up
> > with the process)
> >
> >
> > the processing steps could look like this:
> > [step 1: cron job shell or whatever calls in ant target 'forrestbot']
> > [step 2: this ant target (in the main build file) simply does:]
> >     - depend on init to create build/work output-dir?
> >     - apply config2work xslt on the forrest config to produce
> an ant build
> > file
> >       build/work/work.build.xml >> example attached
> >     - apply (same or other?) config2defaults xslt on the
> forrest config to
> >       produce a build/work/default.properties.xml >> example attached
>
> 1) Why is this step needed? This data is already available in the
> work.build.xml file... is this just for feeding the xmlproperty task?
> Can't the defaults be set in the generated build file directly? That
> means much more XSLT work, of course.

oops... that applydefaults target should of have been removed!
it was my original attempt, but had to replace it with the xmlproperty task
and extra xml file


>
> 2) Alternative approach: from what I understand from your work.build.xml
> sample, I think the defaults can be erased from the work.build.xml file,

as I just confessed...

> and only stored in the generated default.properties.xml (which I would
> call default.parameters.xml, but that is personal taste).
>

+1.
I just luuve people that think about (loads of) file and directory names :-)

> (hmmm... adding that defaulting concept in my original proposal has
> perhaps opened up a can of worms?)
>

nope, I think it's sensible and usefull from the viewpoint of the people
that need to edit the
config file... as long as there is a computer around to do the silly tasks
we should let ease of use prevale.

> >     - copy from forrest-environment to build/work/template.build.xml
> >       >> example template.build.xml attached
> >     - call 'work' target on the newly created work.build.xml
> >
> > [step 3: the 'work' target inside the generated work.build.xml]
> >     - delegate to 'workstage' target for the various stages we define
> >       name of the stage is passed in as a parameter
> >       Currently 5 are foreseen:
> >         - prepare: create build/work/project-name/context directory
> >         - get-src: get the source into that directory,
> >             probably do some other stuff to build a full
> cocoon-context dir?
> >         - generate: run forrest as the cocoon off-line process on that
> >             and dump output in build/work/project-name/build
> >         - deploy: copy/send/checkin/ship/blowup the contents in
> >             build/work/project-name/build
> >         - cleanup: nuke build/work/project-name?
>  >
> > [step 4: the target: workstage:(stage)]
> >     - lists in fact all the ${stage}.SPECIFIC-PROJECT-NAME
> targets to call
> >       (in parallel ?)
> >     - this list comes from the config of course
>  >
> > [step 5: the various generated targets called [workstage].[projectname]
> > will]
> >     - set specific properties based on the config file.
> >       these properties follow names that look like:
> >       [workstage].[action-type].[property-name] reflecting
> >       <workstage
> type="action-type"><property-name>propertyvalue</..></...>
> >     - add up the fall-back properties from the generated
> > default.properties.xml
> >       with an xmlproperty task
> >       this will set fallback values for the same kind of properties...
> >       (same names) that come from the <defaults> section in the config
> >     - call the actual target from the template.build.xml file
> >       that performs (finally) the configured action.
> >
> > [step 6: the template.build.xml file]
> >     - will provide the various template targets that peerform
> the various
> >       supported actions.  These targets will follow names like:
> >       template.[workstage].[action-type]
> >     - they will use the properties described before.
> >
> >
> >>>attached template.build.xml dummy example (only <echo>)
>
> I assume much finetuning for the different tasks will need to be done,
> and they'd better make use of the project-wide parameters being set by
> our Centipede build environment (work dir, location of Cocoon related
> stuff, etc)
>

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?

> > 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 template.build.xml
> > 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
while we're at it, probably build/forrestbot makes more sense then
build/work as a working dir?

>
> > 2. running 'forrestbot' target in build.xml should build
> work.build.xml and
> > default.properties .xml from config.xml
> > 3. build.xml should then delegate to work.build.xml which in
> turn delegates
> > to templates.build.xml
>
> 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'

> > 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
> suggestions/remarks/overlooked
> > gotcha's?
>
> 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.
>

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?


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?


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


-marc=


Mime
View raw message