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=30161>. 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=30161 [PATCH] Impossible to use implicit classpath for <taskdef> when Ant core loader != Java application loader and Path.systemClassPath taken from ${java.class.path} Summary: [PATCH] Impossible to use implicit classpath for <taskdef> when Ant core loader != Java application loader and Path.systemClassPath taken from ${java.class.path} Product: Ant Version: 1.6.1 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Background: http://www.netbeans.org/issues/show_bug.cgi?id=46171 It seems that AntClassLoader.findResources is buggy in case AntClassLoader.parent is something other than ClassLoader.getSystemClassLoader(). The way ClassLoader.getResources works is that the (CL.)parent is first checked and then this.findResources is appended. However ACL never sets CL.parent explicitly; it only used its own independent ACL.parent field, and CL.parent is left at the default value, CL.sCL. This means that ACL.parent.findResources is never called and so any resources that might be contained in it are never found. This can affect e.g. <taskdef> with no explicit classpath. (Note that ACL.getResource (find a single resource) is correct, as far as I know.) Specifically the problem arises when Ant is run from a container such as the NetBeans IDE, for then the class loader which loads Ant core classes is not the app class loader. For example, consider this script: <project default="fail"> <property name="antcontrib.jar" location="/tmp/ant-contrib/lib/ant-contrib-1.0b1.jar"/> <target name="automatic"> <ac:urlencode xmlns:ac="antlib:net.sf.antcontrib" name="encoded" value="hey there"/> <echo>${encoded}</echo> </target> <target name="taskdef-implicit"> <taskdef resource="net/sf/antcontrib/antlib.xml"/> <urlencode name="encoded" value="hey there"/> <echo>${encoded}</echo> </target> <target name="taskdef-explicit"> <taskdef resource="net/sf/antcontrib/antlib.xml" classpath="${antcontrib.jar}"/> <urlencode name="encoded" value="hey there"/> <echo>${encoded}</echo> </target> </project> If antcontrib.jar is in the $CLASSPATH or passed to Ant via -lib, all three targets work. In the IDE, only taskdef-explicit works even if antcontrib.jar is added to the class loader used by Ant core classes (NetBeans #46171)... unless you patch the IDE to set Path.systemClassPath to a path containing the JARs in that class loader. The default value of Path.sCP is taken from the system property ${java.class.path}, which could be just about anything, related to Ant or not. (Ant's launcher hacks around that by faking java.class.path.) Since I know of a workaround for the IDE, I am only submitting this patch for consideration by committers, lest other Ant integrators beat their heads against the wall over this problem. Note that there is a problem with the patch (which is I believe unavoidable unless you set CL.parent correctly, or override CL.getResources in JDK 1.5 where it seems to be nonfinal): if CL.parent (whatever that is) does have any matches for the resource name, and ACL.parent has matches for it that are in fact derived ultimately from CL.parent, ACL.getResources will produce duplicates. I put in a quick hack to avoid this in case CL.parent == ACL.parent, but for a more general fix I suppose you would have to call CL.parent.getResources and remove all such matches before returning them from ACL.findResources. I have not tried such a refinement yet. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]