forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Portier" <...@outerthought.org>
Subject RE: [wip] refactoring the build.
Date Thu, 22 Aug 2002 11:33:48 GMT
<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=


Mime
View raw message