DO NOT REPLY [Bug 6606] - META-BUG problems with delegating classloaders

[bu...@apache.org]

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





------- Additional Comments From jbarnum@360works.com  2005-06-07 15:32 -------
Why not simply remove the optional ant tasks from the classpath in the default install of ant? This 
seems pretty reasonable:

* For those that don't mind modifying their ant home directory, it's not really any extra work: since you 
can't use tasks like <junit> without manually adding junit.jar to the ant lib folder anyway, it doesn't 
seem like much more work to drag in two jars (ant-junit.jar & junit.jar) rather than one (junit.jar) into 
the lib folder.

* For this (like me) who want to create a user-friendly build process that does not require users to 
modify their ant installs, I can redistribute the relevant jars with my project and load them within my 
build.xml file.

I want my users to just be able to download my package and type 'ant' to have everything work. The 
only way I see to do this right now is to copy the source for the JUnit optional task into my own 
package, so that it is not loaded by the core classloader. This is a pretty crummy workaround.

-- 
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org