Charles Benett wrote:
>Here's a thought: can we get rid of all the build.sh/build.bat and
>ant.jar etc?
>
>
>Here's why: as currently written, I think, if you already have ANT_HOME
>defined then the build script won't use jakarta-avalon/tools/lib and so
>will miss optional.jar. (Which makes the junit task fail in excalibur).
>
Allow people building Avalon* to use their own pre-installed Ant ?
-1
Sorry to say. Recipe for disaster IMHO.
My project (Jesktop) has about 20 separate build.xml files. One for
Jesktop and about 19 other that are jesktop compatible applications
(ported and written). They all share one pertinent thing in common and
that is that none of them are distributed with tools/* when being pulled
from the source depot. As part of their build process a 21st
build.bat/sh/xml is invoked called AvalonCommon and that copies (once
off) it's tools/* to the other 20 projects - and that's all it does.
The other 20 can then legitimately have their build.bat/shs invoked.
Also some of the 19 applications are completely dependant on compiled
interfaces from Jesktop ... they relatively get those jars before
compilation.
The whole thing works well if the user has sync'd (checkout) to the root
node of all 21. Even if they have not (they are being selective with
the 19 ... Batik (huge) is one of them) the AvalonCommon/build.xml is
tolerant to missing projects. In fact there is one central build.xml
that cordinates the whole lot and after builds everything website(s)
included.
Ant is not like the JDK. 1.3.1 means something there. Differnet people
have Ant set up differently I use javascript in mine (bsf.jar and js.jar
must be included in tools/lib/ notwithstanding my patch to the Ant-dev
list).
Paul's summary : let Avalon modules <i>relatively</i>coordinate over a
single Avalon defined Ant version that's under CVS control.
Regards,
- Paul H
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
