Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Message-ID: <3D31F206.7030809@outerthought.org>
Date: Sun, 14 Jul 2002 23:49:58 +0200
From: Steven Noels <stevenn@outerthought.org>
Organization: Outerthought
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: forrest-dev@xml.apache.org
Subject: Re: forrestbot for remote projects
References: <LOEAIGHAMOLFGJLAJOFPMEEPDCAA.mpo@outerthought.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Status: O

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.

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, 
and only stored in the generated default.properties.xml (which I would 
call default.parameters.xml, but that is personal taste).

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

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

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

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

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

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
stevenn@outerthought.org                      stevenn@apache.org