DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6606>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6606 META-BUG problems with delegating classloaders ------- Additional Comments From [EMAIL PROTECTED] 2002-02-21 12:18 ------- Bug 5947 offers what I think is a better workaround for JUnit, namely the fork=yes option. True, it's not exactly what I want, but neither is it as complex (in my way of thinking) as disassembling and manually reassembling the ant optional framework. I did come across an aside in the docs mentioning that the classpath wouldn't work unless we fork, but better documentation would help with the understanding so folks like me don't spend hours trying to figure out why the classpath tag isn't working in this excellent new build tool that I'm just beginning to figure out :-) A warning from JUnit when it encounters a classpath tag in a non-fork task that wasn't taskdef'ed would also help to bring attention to the problem and help folks with the workaround without resolving it.How to resolve fully? I'll have to cogitate more on that one. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
