Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs EchoXML.java

On Tue, 21 Jun 2005, Matt Benson <[EMAIL PROTECTED]> wrote: > Oops. You can't blame me, though. I don't. Luckily I still use JDK 1.3 at work to catch this sort of problem. I no longer have access to a 1.2 JDK (haven't tried whether my old Blackdown version still works on Fedora Core 4), so the

Re: FileUtils.close()

Alexey N. Solofnenko wrote: Maybe just ioex.printStackTrace()? I thought it would be better to log to the specific calling task (although getting the error message from the exception makes perfect sense). I seem to recall a complaint about close silent behaviour with a full filesystem and

DO NOT REPLY [Bug 35163] - CVS changelog hangs...

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs EchoXML.java

--- [EMAIL PROTECTED] wrote: > bodewig 2005/06/21 06:39:05 > > Modified: > src/main/org/apache/tools/ant/taskdefs EchoXML.java > Log: > JDK 1.3 doesn't have that constructor (at least > not public) Oops. You can't blame me, though. Why have FileOutputStream(String) FileOutputStre

Re: FileUtils.close()

Maybe just ioex.printStackTrace()? - Alexey. Kev Jackson wrote: This came up before, but I forgot what the consensus was (been a while since I've had time to play with Ant). Whenever FileUtils.close() is used, any resulting exceptions are swallowed and no logging is performed. I'd like to p

cvs commit: ant/src/main/org/apache/tools/ant/taskdefs EchoXML.java

bodewig 2005/06/21 06:39:05 Modified:src/main/org/apache/tools/ant/taskdefs EchoXML.java Log: JDK 1.3 doesn't have that constructor (at least not public) Revision ChangesPath 1.3 +1 -1 ant/src/main/org/apache/tools/ant/taskdefs/EchoXML.java Index: EchoXML.

DO NOT REPLY [Bug 34963] - junit-frames.xsl included with ant does not properly deal with stack traces

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

cvs commit: ant/src/etc junit-frames.xsl junit-noframes.xsl

bodewig 2005/06/21 05:09:25 Modified:.WHATSNEW src/etc junit-frames.xsl junit-noframes.xsl Log: fix PR 34963, create in stack-traces Revision ChangesPath 1.840 +5 -2 ant/WHATSNEW Index: WHATSNEW

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

bodewig 2005/06/21 05:09:06 Modified:src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java Log: fix PR 34963, create in stack-traces Revision ChangesPath 1.11 +1 -1 ant/src/testcases/org/apache/tools/ant/taskde

DO NOT REPLY [Bug 34963] - junit-frames.xsl included with ant does not properly deal with stack traces

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

cvs commit: ant/src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java

bodewig 2005/06/21 04:53:44 Modified:src/etc/testcases/taskdefs/optional junitreport.xml src/testcases/org/apache/tools/ant/taskdefs/optional/junit JUnitReportTest.java Log: Unit test for 34963 Revision ChangesPath 1.3 +10 -0

DO NOT REPLY [Bug 35203] - NullPointerException thrown when using ftp and passive="yes"

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

FileUtils.close()

This came up before, but I forgot what the consensus was (been a while since I've had time to play with Ant). Whenever FileUtils.close() is used, any resulting exceptions are swallowed and no logging is performed. I'd like to propose that instead of this "silent death" for close, that there i