DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH
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=14553. 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=14553 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-07-11 09:52 --- I think the -lib option should make Max happy. -- 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]
DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH
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=14553. 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=14553 Add support for a separate CLASSPATH --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 16:25 --- Ok - I almost rest my case :) ... by using taskdef resource/file one can reduce it to a one-liner, but I still see it as a much cleaner way to specify the tasks available to ant from the outside instead of locally in each build.xml file Actually, I much prefer this one liner that an ANTCLASSPATH. At least some Ant committers prefer explicit things, and the taskdef at the top of all of your build files makes it explicit they are using custom tasks/types. You'll have a hard time introducing a magic feature when there's a clean and simple explicit way to do the same... --DD
DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH
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=14553. 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=14553 Add support for a separate CLASSPATH --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 16:56 --- 1. Do you know about how to import XML fragments into a build file? Look in the ant in anger document with your ant install. Ant1.6 provisionally has an import task to do this more cleanly. 2. if you have 5 custom tasks in one single jar, you only need one taskdef -just point it at a properties file listing taskname=classname mappings.
DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH
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=14553. 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=14553 Add support for a separate CLASSPATH --- Additional Comments From [EMAIL PROTECTED] 2003-03-12 17:15 --- You do not need this functionality for home built tasks; you just include a classpath in the taskdef declarations. You may need it for optional tasks, but you really ought to have the versions of things (like junit) that ant was built against, as differences cause trouble. You may want to know that the startup scripts cause an inordinate amount of support calls, especially related to win9x, cygwin, 4nt, and obscure unix variants, spaces in file and directory names and other little gotchas. For this reason we are very leery of changing them when they seem to work, and are mostly on 'touch only when support calls come in as pre-release testing is impossible'. For this reason, even simple changes are viewed as dangerous. You are of course, free to change your copies. I have been known to have different versions of runant.pl for different projects for related purposes. In ant1.6 we are actually looking at replacing the .bat based classloading process with a boot loader jar, similar to that of tomcat, though performance is potentially an issue there. supporting a new env variable in that process may work. Leaving the report as open till that time.
DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH
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=14553. 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=14553 Add support for a separate CLASSPATH --- Additional Comments From [EMAIL PROTECTED] 2003-03-11 07:02 --- The only libraries you need in the ant dirs are the things that the various optonal ant tasks need: junit, NetComponents, whatever and the xml parsers. But you can isolate your javac and java tasks from these details; I never include the ant lib when I build and run things. What is so wrong with that process? Are you trying to use different versions of junit with the junit task for different projects?
