forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <>
Subject RE: [wip] refactoring the build.
Date Wed, 21 Aug 2002 15:23:21 GMT
> Great :) I'm 100% with you on how you propose to
> separate things.

yep, some minor things I don't really grasp in your summary
some more mail rounds should get it out of the way though.

> A little update on the Maven plugin: I have a basic
<snip about="status and jelly intro"/>

sounds great, and easy to integrate with what we are trying to
as stated before I'ld like maveners (you I guess)
to fill in the gap about making this maven-flavour-distribution
(sorry if I go by at the details at this moment)

> That pattern, of delegating to an Ant script, is what
> I'd like to preserve,

jep. the shell/bat distribution I propose should just be a
wrapper to calling ant
for those that don't want to know about it (inside their
site-building project)
Guess I'm targetting an odd species of users that
1. will install ant because we ask them to
2. then forget about it and only use the ?
in every case IMHO I consider this somewhat better fitting the
forrest scope and goal

<snip />

> In summary; that's what I'm looking for in a
> refactored build system; an Ant
> script(s) which I can create a *minimal* wrapper for,
> to create a Forrest or
> Centipede plugin.

got it. This is called
It will be in there because the shell-bat distribution needs it.
The maven plugin distribution will be able to bundle it as well.

> > This is how I see things end up separated
> >
> > 1. work towards a new build.xml for forrest that
> actually makes
> > forrest-distributions
> >   - 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)
> (cool, but as you say, shell/bat scripts belong in section 2)

catch what you're saying
The numbers (1,2,3) were refering to the number of ant scripts we
should end up with.
So the shell/bat scripts belong (together with the
forrest.buil.xml) inside the ./build/dist/shbat
to be copied to where the forrest-user wants to install it (and
call that location FORREST_HOME)

> >     - 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)
> So here, a 'distribution' is comprised of:
>  1) a directory containing a subset of all Forrest's
> available static files.

yes all different 'distributions' of forrest should have this
this includes cocoon.jar and the like as well. (in fact it has a
WEB-INF with all of that)

>  2) the 'runtime' scripts (shell, bat, ant), that you
> describe below.

small nuance: there is
1. the runtime-ant-script '' that will also be
needed in all distributions of forrest
2. the shell and bat scripts that will only be needed inside the
shbat-distribution of forrest

> The script that generates a distribution (build.xml I
> suggest) will be pretty
> simple; just compile the jars and do lots of copying.

I think the normal build.xml target for the shbat-distribution is
going to be a template for the others..
(as I understand maven and centipede now, that should be indeed a

<snip />

> >   - 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?)
> If you look in acorn.xml, you'll see there's two
> sections, divided by:
> <!-- .............. -->
> <!-- .............. -->
> <!-- .............. -->
> <!-- .............. -->

Jeff, I saw that, only my opinion is that there is 3(2+1)
sections in current acorn.
- targets for building site (html)  for a project that is using
  i.e. what our bot can do for you
  i.e. from having /xdocs to having a set of html files one can
  i.e. the targets you copied from the build.xml (being the ones
that should be removed there)

- targets for creating a template project-content
  i.e. original part of you work with plenty of <echo
  this is what I question to maybe live as a zip of ready made
files inside the distributions
  I guess this is what you call 'seeding the forrest in ones

- targets for getting, building, updating, installing forrest in
  where you do the cvs stuff and the like
  this is what I considered as being the 3rd build file (dropping
the acorn to create the forrest)
  in fact more of an install-script... (sounds like a
meta-pattern all projects could benefit from, you know, the kind
of stuff that maven or centipede would typically solve :-))

> >   - the bot-working targets should slide in here as
> well (anyone
> > having feelings about yet another one?)
> I'd vote for the bot stuff to be put in a separate
> forrestbot.xml script. It's
> still runtime, but it's asynchronous runtime (eg
> cron-driven site updates) that
> won't involve most users.

yes and no
bot is more about centralized/remote site building then it is
about cron
(the ant targets don't know they are called every say 2 hours)
we offer this function as a convenience to our users.
It allows to handle more then 1 project in a sweep
It allows to be ran for you by someone else (that has better
connectvity, or a live point of presance for instance)

(as I tried to explain in an earlier posting: this
centralized/remote running of stuff in fact addresses
cross-project metapattern: maving doing that?)

My separation over 3 build files reflect the lifetime of forrest
on the users hard-disk
- get it, use the following one to build,
install it.
- build.xml: build the distribution of your choice
- use it for the many things forrest can do
for you
   - create empty xdocs structure and files for fresh project
(this you will like to call from sh-bat)
   - generate your doco-site (some of us will like to call from
ant rather)
   - run in remote mode (mostly called by means of sh-bat if you
ask me)

there could be thought of separating these, but IMHO the extra
complexity is not justified by a better user experience, nor by
easier management/maintainability

> > (I'ld like these targets to work eventually on the siteplan
> > idea?)

maven would have no problem with passing a path to a config file
we need, right?

> > (down the line this will call for redoing the bot as well)
> >

To be really honest: down the looooong line: I would rather get
rid of the bot all-together: ant or maven/centipede should do

> >
> > 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
> > version
> > 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.
> This is the second section of acorn.xml. I vote for

I call it the 3rd section of acorn :-)

> turfing out the first
> section, define acorn.xml as "the script for seeding a
> new Forrest project",

yep got that... but I defined 'dropping the acorn' as installing
forrest in FORREST_HOME :-)
it is your metaphore, so you must be right :-)

although this makes me think about that quote about ownership of
metaphores (from the film Il Postino)
"Poems don't belong to those who seed them, but to those who need
them." --Mario Ruoppolo (Massimo Troisi).

> and let a separate script to the actual Forrest running.

there is a separate script for doing the installation stuff (as
said, not top of mind now, something the ant/maven/centipede
blokes should cover for all)

however I consider all of (1) building the site, (2) seeding your
fresh projects (sites), (3) running remote builds of sites as the
full set of what each distribution of ant should be able to
perform.  Therefor putting all of it in one ant file (the
run-time if you like) makes sense to me.

(again, as stated I'll be glad to remove our remote/centralized
solution as soon as some ant/maven/centipede solves it there  -->
let me know when you start on it, I'll be happy to share

> > 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?)
> Let me backtrack and try to summarise what we have so far:
> 1) A 'distribution', containing all the static files
> and compiled jars. This
>    should be generated by the build.xml Ant script.

plus a vision of a time where there could be more then one
these distributions get installed or used as run-time-components
offering the forrest functionality

> 2) Runtime parts of Forrest. Something that, given a
> pointer to 1) and a bunch

why a pointer to 1)? which 1)? (the build.xml or the
- this should not be referring/needing the original build file
any more
- this 'runtime-parts of forrest' == 'the distribution'
(if you meant the latter, I agree to the fact that it needs a
pointer to itself :-))

>    of xdocs, generates a website. The runtime part
> should IMHO be an Ant
>    script, say, called 'forrest.xml'.

I opted for, it says more about what the file
is for, where it relates to (ant in fact)
I still hope we could get it wrapped up as an ant-task as well,
but still offering the wrapping ant-script would be a given.

> 3) Acorn stuff for 'seeding' new projects.

and here we still have some differing ideas:
'seeding new projects' should be included in the runtime
functionality, no?

> So build.xml, when building a distribution, should
> include forrest.xml and
> acorn.xml. Then client projects can do <ant
> antfile="${forrest.home}/forrest.xml"/>.
> If we want shell/bat scripts, does that imply bundling
> Ant into the
> distribution? I'd really rather not include Ant, since

same opinion here.
require ant: yes
include ant: no

> most Forrest users will
> be invoking Forrest from their own Ant scripts (ant
> preinstalled), or
> indirectly via Maven or Centipede.

even the ones that are not on a software-project, but on pure
doco or site-project will need ant to be able to use forrest....

surely for those the meta-install-your-project idea could be
useful: call in dependencies on other projects to be installed
and all... mmmm

> However, if you mean shell/bat scripts that just runs
> Cocoon directly, then
> that's great.
> > Anyone care to join in the fun?
> > Can I commit the very general (non-working)
> framework (==set of
> > new buildfiles) I already have?
> Please do, I'd like to see how it's going. It sounds
> like we're definitely on
> the same wavelength.

getting there, buddy....

PS: I'll check-in before going off-line, will be tomorow before I
can add more. I suggest to comment/agree on the structure and
then talk about deviding the work maybe? I guess this is not
blocking you?

View raw message