forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <>
Subject [wip] refactoring the build.
Date Wed, 21 Aug 2002 11:42:28 GMT
Hi all,

I've started on the topic Jeff put on the agenda: separating the
concerns in our build system.
I understand touching the build system is of the rather
disturbing kind.
On the other hand, the relative silence on the list could be a
sign that this is good timing?

This is how I see things end up separated

1. work towards a new build.xml for forrest that actually makes
  - remove all forrest-site producing targets
  - insert actual forrest-distributions
    - the one I like to build now is some kind of shell/bat
version of forrest. (see below)
    - what I am dreaming (no clue how to do it) of is other
targets to build (1) cent / (2) jar (standalone and with ant task
included) / (3) maven-plugin /...? (I hope maveners and
centipeders will step in further down the line)

I'm creating a currently so the old one keeps
working while doing this wip
We can have a vote on replacing one by the other as soon as
things stabalize?
Or would anyone rather call for branches?
Last alternative would be to work on build.xml itself in a way
that doesn't break?
(I would rather keep it separate though, just have to track
ammendments on build.xml for the time being)

2. work towards a separate that handles the
run-time part of what forrest can do for any project
  - place here the forrest-site producing things in such a way it
can work on other projects
    so we go here for bot-like tasks that use
parameters (also the webapp target makes sense)
  - part of acorn should go in here as well: the targets to build
your fresh-project-template
    (I like the way it builds file from inside the ant file,
although I think to some copying a set of premade-termplate files
would make it easier to manage the template content? e.g. also
for when users would like to customise this template?)
  - the bot-working targets should slide in here as well (anyone
having feelings about yet another one?)

(I'ld like these targets to work eventually on the siteplan
(down the line this will call for redoing the bot as well)

3. work towards a separate that captures the
acorn-dropping idea
  - look at forrest.home to install or update the thing there.
  - get it from cvs and build it again to overwrite the other
This last one is handy, but less of a priority maybe? Cent users
would get this kind of feature from the cent behaviour, don't
know about maven on this.

As for the (only) distribution I think on building now:
That would very much behave like ant.bat:  So people using
forrest for their project should install this distribution in
some directory, put its path in env: FORREST_HOME, add the bin
section of it to their path and call the there residing
forrest.bat or
Pretty much like they use ant to build their classes, they should
use forrest to build their site then.
People that like to hook up this work in their chain of ant
dependencies can just call the shell by means of <exec>
This distribution will itself call upon ant to do the actual
building: the 2nd one of the build files should be in here!
Given this fact, it would probably be a lot cleaner for people
that want to use forrest from their ant script to use <ant
antfile=${ENV.FORREST_HOME}/ ...> in stead.
(Still, making it possible for them to just type
($FORREST_HOME/bin/) on the command-line kinda sounds
nice.  It would let them - produce the fresh project template
(like acorn) - produce the docs and the webapp - to run as a
bot... furthermore: site-building based on forrest should be open
to non-programming-projects (no build.xml) as well, no?)

Anyone care to join in the fun?
Can I commit the very general (non-working) framework (==set of
new buildfiles) I already have?

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

View raw message