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=26570>. 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=26570 duplicate instances of interface com.sun.javadoc.RootDoc loaded ------- Additional Comments From [EMAIL PROTECTED] 2004-02-05 07:49 ------- If you prefer you may use the old ant.bat/lcp.bat combination to start Ant without the new launch code. This should give you the same class loader config as Ant 1.5. You may run into command line length limits under Windows when doing so. If necessary this could be added to the release as ant-compat.bat. I would note that creation of a URLClassLoader without specifying a parent, assumes the availability of classes in the system loader. This assumption, in turn, limits you to certain configurations of Ant. For example, an IDE which runs Ant natively, even based on Ant 1.5, is unlikely to run your build properly since it's system loader will not necessarily have the required classes. This is not quite an issue of Ant providing a runtime environment that is the same as compile time. Ant does that already as a task has access to tools.jar, ant.jar and the ant libraries. Rather it is the code that is in the custom task that is not providing that runtime environment, by making assumptions about the content of the system classloader. I was hoping you would clarify the usage of the Context ClassLoader you mentioned briefly as it may offer a workaround in the form of a wrapper task or something similar. IOW, derive a new task from the one you can't change and in it's execute methos set the context classloader, then invoke super.execute(). If the custom task uses the context class loader you'd have a workaround. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
