You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Marc Portier <mp...@outerthought.org> on 2002/08/21 13:42:28 UTC
[wip] refactoring the build.
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
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)
- 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 build.build.xml 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 forrest.build.xml 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 template.build.xml 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
idea?)
(down the line this will call for redoing the bot as well)
3. work towards a separate install.build.xml 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.
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 forrest.sh.
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}/forrest.build.xml ...> in stead.
(Still, making it possible for them to just type
($FORREST_HOME/bin/)forrest.sh 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=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
mpo@outerthought.org mpo@apache.org
Re: Cross-project integration w/ Maven (Re: [wip] refactoring the
build.)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Jeff Turner wrote:
> On Thu, Aug 22, 2002 at 01:33:48PM +0200, Marc Portier wrote:
>
>>>>(as I tried to explain in an earlier posting: this
>>>>centralized/remote running of stuff in fact addresses
>>>>cross-project metapattern: maving doing that?)
>>>
>
>>>Not explicitly, though IIRC some plugins do offer
>>>remote deployment, and
>>>Maven's reactor lets you run targets in multiple
>>>projects, taking into account
>>>inter-project dependencies.
>>>
>>
>>this does interest me, some directed pointer to a doc that
>>explains more?
>
>
> There are no formal docs on the reactor, just some emails[1] and IRC
> logs. Currently it's like a <foreach> tag that iterates over projects,
> sorts them by inter-project dependency, and runs some targets.
Hmmm... ever heard of Gump? ;-)
> Here's an
> impressive demonstration of inter-project consistency:
>
> http://jakarta.apache.org/~jvanzyl/jakarta-commons/index.html
Impressive? Yeah, if I have all the docs in the same format I can do
that with a couple of lines in an Ant buildfile.
> Here is the Commons maven.xml file that generates that site:
>
> http://cvs.apache.org/viewcvs/jakarta-commons/maven.xml?rev=1.5&content-type=text/vnd.viewcvs-markup
>
>>>From various emails[2,3], it sounds like they want to extend Maven to be
> a Cruisecontrol-like continuous integration tool, replacing Gump, doing
> nightly builds etc.
Gump already does it, nothing new under the sun.
Centipede uses Gump descriptors for regular compilation, so that they
can be kept more uptodate.
> In other words, Maven is well on it's way to achieving many of the goals
> in Forrest's "dream list". That's why I think Forrest as a tightly
> integrated Maven plugin would be pretty neat.
Forrest will remain Forrest, which means that it must me able to work
- by itself
- in Ant
- in Maven
- you name it
Forrest is already working as a bot since some time now.
That's why I think Maven as a tightly integrated Forrest plugin would be
pretty neat. ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Cross-project integration w/ Maven (Re: [wip] refactoring the build.)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Aug 22, 2002 at 01:33:48PM +0200, Marc Portier wrote:
> > > (as I tried to explain in an earlier posting: this
> > > centralized/remote running of stuff in fact addresses
> > > cross-project metapattern: maving doing that?)
> > Not explicitly, though IIRC some plugins do offer
> > remote deployment, and
> > Maven's reactor lets you run targets in multiple
> > projects, taking into account
> > inter-project dependencies.
> >
>
> this does interest me, some directed pointer to a doc that
> explains more?
There are no formal docs on the reactor, just some emails[1] and IRC
logs. Currently it's like a <foreach> tag that iterates over projects,
sorts them by inter-project dependency, and runs some targets. Here's an
impressive demonstration of inter-project consistency:
http://jakarta.apache.org/~jvanzyl/jakarta-commons/index.html
Here is the Commons maven.xml file that generates that site:
http://cvs.apache.org/viewcvs/jakarta-commons/maven.xml?rev=1.5&content-type=text/vnd.viewcvs-markup
>From various emails[2,3], it sounds like they want to extend Maven to be
a Cruisecontrol-like continuous integration tool, replacing Gump, doing
nightly builds etc.
In other words, Maven is well on it's way to achieving many of the goals
in Forrest's "dream list". That's why I think Forrest as a tightly
integrated Maven plugin would be pretty neat.
--Jeff
[1] http://marc.theaimsgroup.com/?t=102752298900005&r=1&w=2
[2] http://marc.theaimsgroup.com/?t=102752298900005&r=1&w=2
[3] http://marc.theaimsgroup.com/?l=avalon-dev&m=102992940308157&w=2
RE: [wip] refactoring the build.
Posted by Marc Portier <mp...@outerthought.org>.
<snip />
> I think you need to cultivate a sense of fear and
> loathing for scripts :) They
> start out nice and simple, and turn into monstrosities
> like ant's when trying
> to cater for MacOS, cygwin, etc.
>
indeed.
occasionally they do something usefull as well.
<snip />
>
> > (as I tried to explain in an earlier posting: this
> > centralized/remote running of stuff in fact addresses
> > cross-project metapattern: maving doing that?)
>
> Not explicitly, though IIRC some plugins do offer
> remote deployment, and
> Maven's reactor lets you run targets in multiple
> projects, taking into account
> inter-project dependencies.
>
this does interest me, some directed pointer to a doc that
explains more?
> > My separation over 3 build files reflect the
> lifetime of forrest
> > on the users hard-disk
> > - install.build.xml: get it, use the following one to build,
> > install it.
> > - build.xml: build the distribution of your choice
> > - forrest.build.xml: 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)
>
> All sounds good. Let's take a bet on this shell/bat thing ;)
>
since it comes with the ant-build-script underneath you are
invited to ignore :-)
<snip />
>
> > To be really honest: down the looooong line: I would
> rather get
> > rid of the bot all-together: ant or maven/centipede should do
> > this.
>
> Well part of Jason's World Domination plan includes
> adding 'continuous
> integration' facilities to Maven, to do Gump-like
> things like nightly builds,
> and I guess, site updates.
>
Is this the reactor thing again?
> > yep got that... but I defined 'dropping the acorn'
> as installing
> > forrest in FORREST_HOME :-)
>
> Nono.. acorns you drop into *new* projects, where they
> then grow into new
> forrests.
>
that is why I thought: _one_ forrest (the project) should be
enough :-)
but getting it to be used by more projects is the goal, so I
concede to any labeling as long as we get there.
<snip hide="lame stuff" />
> > > 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
> > distribution?)
>
> The distribution. Ie, it needs ${forrest.home} defined.
>
yo man.
that is the case
> > - 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 :-))
>
> I thought that the script might need to be in the
> project's directory, not
> Forrest's. That's because in Ant, there is no
> equivalent of $PWD. 'basedir' is
> of no use. If that can be worked around, great.
>
so you discover why I have a shell script :-)
users of ant-directly could call upon the runtime-build-file with
<property name="forrest.home" value="${ENV.FORREST_HOME}" />
the shell script will add -Dforrest.home=$FORREST_HOME for you
and will remember where (in your project-directory) you started
the shell -Dproject.home=$PWD
(the latter is fun in DOS batch scripting :-) )
> > > of xdocs, generates a website. The runtime part
> > > should IMHO be an Ant
> > > script, say, called 'forrest.xml'.
> >
> > I opted for forrest.build.xml, it says more about
> what the file
> > is for, where it relates to (ant in fact)
>
> But it doesn't "build forrest" :) It runs forrest. And
> double dots confuse
> certain braindead OSs..
>
mmm, I have this idea going on using the multi-dot filenames it
just about everywhere
how much should we care?
How braindead are these OS's? (if they don't run java/ant/cocoon
i don't think we should consider since that are dependencies for
our existence to start with)
Any examples?
> > > 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?
>
> Yes I guess it should.
> /usr/local/forrest/seed_new_project.sh
so what about:
%FORREST_HOME%\bin\forrest.sh seed
<snip />
> So far acorn.xml is doing okay as the Forrest plugin
> backend. I'll migrate to
> forrest.build.xml as soon as it's functional.
>
fair enough.
looking forward to adding the maven and centipede targets in the
build.
I hope on finishing this weekend, intermediates available as we
go along.
-marc=
Re: [wip] refactoring the build.
Posted by Jeff Turner <je...@apache.org>.
On Wed, Aug 21, 2002 at 05:23:21PM +0200, Marc Portier wrote:
>
> 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 forrest.sh ?
I think you need to cultivate a sense of fear and loathing for scripts :) They
start out nice and simple, and turn into monstrosities like ant's when trying
to cater for MacOS, cygwin, etc.
> 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
> it
...
> - targets for creating a template project-content
...
> - targets for getting, building, updating, installing forrest in
> some FORREST_HOME
...
That extra separation makes sense. At least, logically, dunno about
physically.
> > 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)
Cool.
> (as I tried to explain in an earlier posting: this
> centralized/remote running of stuff in fact addresses
> cross-project metapattern: maving doing that?)
Not explicitly, though IIRC some plugins do offer remote deployment, and
Maven's reactor lets you run targets in multiple projects, taking into account
inter-project dependencies.
> My separation over 3 build files reflect the lifetime of forrest
> on the users hard-disk
> - install.build.xml: get it, use the following one to build,
> install it.
> - build.xml: build the distribution of your choice
> - forrest.build.xml: 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)
All sounds good. Let's take a bet on this shell/bat thing ;)
> > > (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?
Nope.
> To be really honest: down the looooong line: I would rather get
> rid of the bot all-together: ant or maven/centipede should do
> this.
Well part of Jason's World Domination plan includes adding 'continuous
integration' facilities to Maven, to do Gump-like things like nightly builds,
and I guess, site updates.
> yep got that... but I defined 'dropping the acorn' as installing
> forrest in FORREST_HOME :-)
Nono.. acorns you drop into *new* projects, where they then grow into new
forrests.
I hereby rename 'acorn' to 'acorrn' :)
No that's too lame, I take it back.
...
> > 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
> distribution?)
The distribution. Ie, it needs ${forrest.home} defined.
> - 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 :-))
I thought that the script might need to be in the project's directory, not
Forrest's. That's because in Ant, there is no equivalent of $PWD. 'basedir' is
of no use. If that can be worked around, great.
> > of xdocs, generates a website. The runtime part
> > should IMHO be an Ant
> > script, say, called 'forrest.xml'.
>
> I opted for forrest.build.xml, it says more about what the file
> is for, where it relates to (ant in fact)
But it doesn't "build forrest" :) It runs forrest. And double dots confuse
certain braindead OSs..
> > 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?
Yes I guess it should.
/usr/local/forrest/seed_new_project.sh
> > distribution? I'd really rather not include Ant, since
>
> same opinion here.
> require ant: yes
> include ant: no
good-o
...
> -marc=
> 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?
So far acorn.xml is doing okay as the Forrest plugin backend. I'll migrate to
forrest.build.xml as soon as it's functional.
--Jeff
--
Hell is a state of mind. And every state of mind, left to itself,
every shutting up of the creature within the dungeon of it's own
mind -- is, in the end, Hell.
C.S. Lewis, _The Great Divorce_
RE: [wip] refactoring the build.
Posted by Marc Portier <mp...@outerthought.org>.
> Getting the plugin size down from 11mb would also be
> good :) There's Ant
> and all sorts of unused crud in there now.
>
>
yes,
but, at least to me, this is not like top of mind :-(
> --Jeff
>
>
Re: [wip] refactoring the build.
Posted by Jeff Turner <je...@apache.org>.
On Thu, Aug 22, 2002 at 11:14:12AM +1000, dion@multitask.com.au wrote:
> Jeff, this looks great....
>
> Is forrest-acorn at a point where we could add it as a maven plugin for
> the next release?
Not really, it's mostly a proof of concept at the moment. The biggest
issue is mapping things from Maven-land to Forrest-land:
- Directory structures need to be mapped, eg xdocs ->
src/documentation/content/xdocs. Complicated by the fact that the
Cocoon sitemap is static.
- XML files need to be translated from Maven's dodgy-DTDless-XML to
Forrest's document-v11.dtd format, with an XSLT.
- A bunch of XSLTs need to be written to convert Maven's generated xdocs
into something Forrest can use.
Eventually, I hope to have the Forrest plugin as a drop-in replacement
for the xdoc plugin. People can then start with xdoc, and if they need
something more versatile (but slower) they can switch to Forrest.
Getting the plugin size down from 11mb would also be good :) There's Ant
and all sorts of unused crud in there now.
--Jeff
RE: [wip] refactoring the build.
Posted by Marc Portier <mp...@outerthought.org>.
> 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
though
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
do,
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 forrest.sh ?
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 forrest.build.xml.
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 'forrest.build.xml' 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.
>
yes.
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
snap)
<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
it
i.e. what our bot can do for you
i.e. from having /xdocs to having a set of html files one can
publish
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
file="....xml"><[CDATA[...
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
project'
- targets for getting, building, updating, installing forrest in
some FORREST_HOME
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
- install.build.xml: get it, use the following one to build,
install it.
- build.xml: build the distribution of your choice
- forrest.build.xml: 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
this.
> >
> > 3. work towards a separate install.build.xml 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
thoughts)
>
> > 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 forrest.sh.
> > 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}/forrest.build.xml ...> in stead.
> > (Still, making it possible for them to just type
> > ($FORREST_HOME/bin/)forrest.sh 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.
yep.
plus a vision of a time where there could be more then one
'distribution-flavor'
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
distribution?)
- 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 forrest.build.xml, 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....
-marc=
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?
Re: [wip] refactoring the build.
Posted by di...@multitask.com.au.
Jeff, this looks great....
Is forrest-acorn at a point where we could add it as a maven plugin for
the next release?
Jeff Turner <je...@apache.org> wrote on 21/08/2002 11:34:11 PM:
> Great :) I'm 100% with you on how you propose to separate things.
>
> A little update on the Maven plugin: I have a basic version working,that
just
> delegates to acorn.xml. Maven plugins are really easy. They're
basically a
> Jelly script, plugin.jelly, which gets automatically 'sourced', and gets
a
> pointer to ${plugin.dir} where one can store static resources
(dtds,xsls, jars
> etc). So my plugin.jelly just delegates to Ant:
>
> <project xmlns:j="jelly:core" xmlns:define="jelly:define">
> <goal name="forrest:transform">
> <property name="forrest.home" location="${plugin.dir}/xml-forrest"/>
> <ant antfile="${plugin.dir}/acorn.xml">
> <property name="forrest.home" value="${forrest.home}"/>
> </ant>
> </goal>
> </project>
>
> That pattern, of delegating to an Ant script, is what I'd like to
preserve,
> because then we can reuse the Ant script across Centipede, Maven,
command-line
> and from user's Ant scripts. All the Maven plugin does is map from
Maven's
> directory layout (${maven.*} properties) to Forrest's dir layout.
>
> 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.
>
--
dIon Gillard, Multitask Consulting
Work: http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers
Re: [wip] refactoring the build.
Posted by Jeff Turner <je...@apache.org>.
Great :) I'm 100% with you on how you propose to separate things.
A little update on the Maven plugin: I have a basic version working, that just
delegates to acorn.xml. Maven plugins are really easy. They're basically a
Jelly script, plugin.jelly, which gets automatically 'sourced', and gets a
pointer to ${plugin.dir} where one can store static resources (dtds, xsls, jars
etc). So my plugin.jelly just delegates to Ant:
<project xmlns:j="jelly:core" xmlns:define="jelly:define">
<goal name="forrest:transform">
<property name="forrest.home" location="${plugin.dir}/xml-forrest"/>
<ant antfile="${plugin.dir}/acorn.xml">
<property name="forrest.home" value="${forrest.home}"/>
</ant>
</goal>
</project>
That pattern, of delegating to an Ant script, is what I'd like to preserve,
because then we can reuse the Ant script across Centipede, Maven, command-line
and from user's Ant scripts. All the Maven plugin does is map from Maven's
directory layout (${maven.*} properties) to Forrest's dir layout.
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.
On Wed, Aug 21, 2002 at 01:42:28PM +0200, Marc Portier wrote:
> 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
> 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)
> - 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.
2) the 'runtime' scripts (shell, bat, ant), that you describe below.
The script that generates a distribution (build.xml I suggest) will be pretty
simple; just compile the jars and do lots of copying.
...
> 2. work towards a separate forrest.build.xml 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 template.build.xml tasks that use
> parameters (also the webapp target makes sense)
(and that I can call from a jelly script)
> - 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:
<!-- .............. -->
<!-- .............. -->
<!-- .............. -->
<!-- .............. -->
The first section is what you want here; targets for rendering existing docs in
arbitrary directories. I took these directly from Forrest's build.xml, with
minimal modification. It's ugly and needs rewriting. This is what I'd be
working on next, and (it sounds like) what you're working on now? Can I help,
or would you like me to do it?
> - 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.
> (I'ld like these targets to work eventually on the siteplan
> idea?)
> (down the line this will call for redoing the bot as well)
>
>
> 3. work towards a separate install.build.xml 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 turfing out the first
section, define acorn.xml as "the script for seeding a new Forrest project",
and let a separate script to the actual Forrest running.
> 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 forrest.sh.
> 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}/forrest.build.xml ...> in stead.
> (Still, making it possible for them to just type
> ($FORREST_HOME/bin/)forrest.sh 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.
2) Runtime parts of Forrest. Something that, given a pointer to 1) and a bunch
of xdocs, generates a website. The runtime part should IMHO be an Ant
script, say, called 'forrest.xml'.
3) Acorn stuff for 'seeding' new projects.
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 most Forrest users will
be invoking Forrest from their own Ant scripts (ant preinstalled), or
indirectly via Maven or Centipede.
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.
--Jeff
> -marc=
>