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=14931>. 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=14931 taskdef ignores classpath attribute in some cases Summary: taskdef ignores classpath attribute in some cases Product: Ant Version: 1.5.1 Platform: All OS/Version: All Status: NEW Severity: Minor Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A <taskdef> ignores its stated classpath settings in cases when the classname attribute can be resolved via the default ant classpath. This setup: <path id="junit.runtime.path"> <pathelement location="${cvs.checkout}/gate5ag/Devel/Java/Lib/jakarta/ant-optional.jar" /> <pathelement location="${cvs.checkout}/gate5ag/Devel/Java/Lib/junit/junit.jar" /> </path> <taskdef name="junit" classname="org.apache.tools.ant.taskdefs.optional.junit.JUnitTask" classpathref="junit.runtime.path" /> gives me a ClassNotFoundExc because junit.framework.TestListener cannot be found if optional.jar is in $ANT_HOME/lib, and junit.jar is not. Removing optional.jar from $ANT_HOME/lib fixes this; adding junit.jar to $ANT_HOME/lib does fix it as well. Seems to me that taskdef ignores my classpath if it can load org.apache.tools.ant.taskdefs.optional.junit.JUnitTask via the default classloader, then tries to load the junit classes via the default CL as well. Of course this fails in the above setup. Why does taskdef use the boot CL in the first place? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
