On Monday, July 8, 2002, at 11:33 AM, Diane Holt wrote:
> --- Scott Ellsworth <[EMAIL PROTECTED]> wrote: >> About the only complaint I am getting is that since I cannot use both >> a MailLogger and a NoBannerLogger, the "build failed" emails from our >> project are quite long. > > Couldn't you just copy MailLogger.java (to wherever in your tree you > keep custom Ant things) and change it to extend NoBannerLogger instead > of DefaultLogger? (Didn't try it, since I don't have any mail set up on > my machine, but it seems like that should work.) I certainly could, I suspect. At this point, I have a task that extends "Java", and thus I already have some of the machinery in place. Can I load that with a taskdef, or must it go in ant/lib? I have a question about the classpath. Are the ant and optional jars in the compiler classpath when things are set up in the out of the box fashion? If I understand things properly, the ant classes are not in the classpath by default, so if I wish to compile a new logger, or a new task, I have to have ant.jar in a known spot on the classpath. Our build system is explicitly not allowed to know the location of the build tools, so to compile an ANT task or logger, I have to put a copy of ANT jar in our "third party libraries to be compiled against". This worries me, as it opens us up to classloader problems like xalan shows. I would much rather have our tools compile against the version of ANT that we are compiling with. This makes it harder to do a build of that tool or logger under a tool other than ANT, but I am willing to accept that difficulty. Is my understanding correct? As an alternative - how hard would it be for the official distribution to have an interfaces.jar containing only those types and interfaces that people are to be extending, and thus less likely to change over time? Scott -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
