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 [EMAIL PROTECTED] 2005-11-02 20:52 ------- (In reply to comment #25) > 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. I think this is the best all-around solution to the problem, with one addition: Put the optional ant tasks into a separate folder (optional/lib, opt/lib or some such) and then add a default property called ant.optional.library.dir that is similar to the ant.library.dir except that it points to this new optional library directory. This way, if you want to use an optional task you can simply include the external jars in your distribution and then write a taskdef whose classpath includes the appropriate optional.jar file and its dependencies. While this does create a little more work for anyone wanting to use the optional tasks, the volume of help requests would be simplified by adding an sample taskdef to the doc page of each optional task. As it stands right now, the only workable solution to this problem makes ant much less useful to people trying to build code rather than people trying to write ant scripts. I would imagine that usability should focus first on people trying to build code before it focuses on people trying to write ant scripts because (typically) the person writing the ant script will be somewhat more technical than the other. Besides, it makes the ant script more self documenting with respect to its dependencies. -- 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]
