Sorry Mariusz, but I'd have to agree with Diana about this one. There may have been a good reason for the user for specifying a non-standard (i.e.: classic or modern) compiler (e.g.: compiler coverage). By automatically picking a different compiler because it can't be found I don't think is a good default behaviour.
I also don't think that making the ant tool itself interactive is a good idea either. A good percentage of the loadbuild departments I've seen use their loadbuild tools in a non-interactive way. For example, performing nightly loadbuilds through cron jobs. I believe that the ant tool itself shouldn't be interactive, but that the Ant GUI could/should be. I view the ant tool as more of an API then a tool. Tolls will sometimes interact with humans, but API rarely do. JDGlanville > -----Original Message----- > From: Diane Holt [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 20, 2000 8:49 PM > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] attempt 2 at javac refactoring. > > > I agree about not losing the compiler property -- I need to > specify which > compiler is being used going in. > > But I have to disagree with this idea: > > > And, I also think, that old modern and classic compilers should be > > special, I mean, if I set compiler to be jikes, and jikes is not > > installed > > on the user site, current ANT throws an exception. I think > more robust > > would be to issue a warning, and try to compile with > modern, and if this > > one is not present either, try classic. Thus it would be > great in case > > of failure of any "custom" compiler, trying modern then classic. > > This would be a very bad idea, as far as I'm concerned -- I can't just > have things compiling willy-nilly with any old compiler Ant happens to > find. Yikes! Which compiler I'm using needs to be a very > controlled aspect > of the build. > > Diane
