ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH
Date Wed, 12 Mar 2003 17:15:19 GMT
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 stevel@apache.org  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.

Mime
View raw message