Pete, > Hi, > > I been thinking that to actually accomplish the flexability in the build > process that everyone seems to want we are going to either end up with a > forest of mangled scripts. For a while now I have been using another set of > bootstrap scripts that bootstrap the bootstrap ;) so as to enable all the > things that I want/don't want and to actually make it compile (ie define > CLASSPATH, define ANT_HOME, define JAVA_HOME, define JAVAC, define ... etc) > > Ages ago bootstrapping current ant with an old ant was vetoed IIRC but I > would like to make a case for it. I would like to see an old version of ant > kept in CVS (say last released version). This would give us all heaps of > flexability and it would void the need for maintaining the complex > platforms specific scripts that we currently use. The main reason this was > vetoed last time was because it involved keeping jars in CVS and as this is > no longer so taboo maybe we could change it ?
-1 The reason using an old ant.jar is bad is that it would prevent us having an ant build file with any new features. For example, would you have been happy to release an ant 1.2 which had to build with ant 1.1's ant.jar, therefore using a build.xml file which included all the deprecated copy, delete tasks etc. It is important to be able to build ant completely from source. I am strongly against an ant.jar in CVS. Putting other jars in CVS is one thing (which I still do not support), but ant.jar is another. > > The only real other option is to build a Bootstrap.java that we use to > bootstrap the process. However this would be just as brittle and > unmaintainable as the other techniques - just in java. I am happy to play with the AntEater bootstrap concept but we are a little away from using that in a real build. In truth the previous scripts have been happily building ant for many months. If you look at the old build.bat, you will see that it was a very thin wrapper for ant.bat which is part of the distribution anyway. This file was only 15 lines long. Bootstrap.bat did not call build.bat, but simply invoked Ant directly with Java. There was careful separation between the ant being built and the one doing the build (the bootstrapped ant). The present situation is very much different. build.bat is 3 times bigger and duplicates most of ant.bat. build.bat calls bootstrap.bat which then calls build.bat. The classes being run and also being written on. I think the suggestion that these files are unmaintainable or brittle is questionable. If we look at the CVS activity on these files after July (when I rewrote most of them) up until the recent changes we have build.bat 2 changes build.sh no changes bootstrap.bat 6 changs bootstrap.sh 14 changes ant.bat 10 changes ant 10 changes If we compare build.xml over the same timeframe there are about 70 changes. I presume you are not suggesting doing away with ant.bat and so, the only other script with any meat it was the bootstrap script. I wouldn't have called it a "forest of mangled scripts". What do we go now? I am getting uncomfortable about the churn in the build process as we run up to a new release. I would vote to roll back the scripts but look at retaining the build.xml changes for the new build locations, etc. Conor
