ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: Ant build.xml
Date Fri, 07 Apr 2000 01:54:10 GMT


>> This will mean that the Tomcat tree will need to include an ant##.jar
>> representing the latest stable ant.  No more bootstrapping.  Maybe
>> that's a good thing?  :-)
>
>Yep. Bootstrapping was intended to be used only for compiling in
>non-compatible changes to Ant itself. Nobody else the world should have to
>do it, nor should you have to do it often yourself. You should be able to
>use an older version of ant to compile a newer one (assuming you placed
the
>jar on your classpath somewhere safe and aren't using the one that's being
>built by the workspace).

I respectfully disagree.  The last thing we need is for every project that
is a building block to contain their own version of ant, xml parser, and
tools.jar.  What a mess.  Ever few weeks there is a report on the cocoon
mailing list of a problem that is due to somebody having an old xml parser
with a backlevel set of org.w3c classes earlier in their classpath,
breaking cocoon.

In general, I am totally -1 against checking in outputs from build
processes.  The only exception I can conceive of are projects which are top
levels (i.e., not typically used as building blocks).

A much better model IMHO is the RedHat model.  Every six months or so a
complete package is built where everything was built using the same version
of everything.  From this one image, you can install the binaries from the
pieces you want and replace the others either with alternate binaries
(RPMs) or by compiling them yourself from source.

- Sam Ruby



Mime
View raw message