No, I meant w.r.t. recompiling/importing any "extension" or "optional" .jar files that are used to implement features not a part of the "core".
-Peter > -----Original Message----- > From: James Duncan Davidson [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 27, 2000 10:33 PM > To: [EMAIL PROTECTED] > Subject: Re: Did somebody say Shut up and Write? :) > > > On 12/27/00 1:27 PM, "Peter Vogel" <[EMAIL PROTECTED]> wrote: > > > In other words, a proper tree build, under all of these > proposals, will happen > > as follows: ant is invoked ant *possibly* builds extensions > to itself ant > > invokes new version of ant to continue the build ant builds > rest of tree > > Actually ant wouldn't necessarily need to invoke a new > version of itself to > build -- it can just load in the classes using a class loader. > > > It could be argued, I suppose, that the CM group would > "own" ant and be > > responsible for ensuring that all developers always have an > up-to-date version > > of ant for their tree, but that assumes the presence of a > true CM group, etc. > > which may not be the case for many organizations. > > > By "Ant building itself" do you mean refreshing out the core > to keep an > up-to-date version? If so, I could think of doing something like an: > > `ant -selfupdate` > > Which would hit the distribution site and see if it needed to > get new code. > Of course this wouldn't be default behavior since you don't > always have a > network connection. And of course, you don't want to pull > straight out of > CVS as that might not be as stable. You'd want it searching on the > milestones or some such. > > Or, another possibility is for Ant to check every n days for > a new version. > > .duncan > > -- > James Duncan Davidson > [EMAIL PROTECTED] > > !try; do() > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
