DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.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://issues.apache.org/bugzilla/show_bug.cgi?id=6606 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[EMAIL PROTECTED] ------- Additional Comments From [EMAIL PROTECTED] 2005-05-31 23:37 ------- (In reply to comment #22) > I changed the ant-junit.jar so it does not load/reference any > junit classes before it forks a new JVM. That way the classloader problems > disappear since junit classes are not loaded inside ant's JVM. This could be quite useful. E.g. the NetBeans IDE uses http://www.netbeans.org/download/dev/javadoc/org-apache-tools-ant-module/org/apache/tools/ant/module/spi/AutomaticExtraClasspathProvider.html from the module bundling junit.jar in order to force it to be added to Ant's primary classpath. Even though the build scripts that the IDE generates will have an explicit path for junit.jar - which is used e.g. when compiling unit tests - it cannot currently run <junit> unless this has been done. A patch such as is described here would make it possible to do omit junit.jar from Ant's primary classpath, and would mean that a command-line build incl. unit testing would succeed so long as the path was set up correctly, without requiring the user to run Ant with junit.jar in $CLASSPATH (or ant/lib/ or whatever). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
