forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <>
Subject forrestbot for remote projects
Date Sat, 13 Jul 2002 18:15:15 GMT
old discussions revived:

this mail proposes a step-by-step approach to implement the remote building
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
      build/work/ >> example attached
    - apply (same or other?) config2defaults xslt on the forrest config to
      produce a build/work/ >> example attached
    - copy from forrest-environment to build/work/
      >> example attached
    - call 'work' target on the newly created

[step 3: the 'work' target inside the generated]
    - 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
        - 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]
    - 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
      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 file
      that performs (finally) the configured action.

[step 6: the file]
    - will provide the various template targets that peerform the various
      supported actions.  These targets will follow names like:
    - they will use the properties described before.

>> attached dummy example (only <echo>)

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

Steven volunteered on creating the needed xslt
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

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center            

View raw message