>> 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
