PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2611 *** shadow/2611 Mon Jul 30 23:11:46 2001 --- shadow/2611.tmp.4070 Sun Aug 12 01:34:14 2001 *************** *** 2,9 **** | Automatic modification of standard classpath | +----------------------------------------------------------------------------+ | Bug #: 2611 Product: Ant | ! | Status: REOPENED Version: 1.3 | ! | Resolution: Platform: Other | | Severity: Enhancement OS/Version: Other | | Priority: Other Component: Core | +----------------------------------------------------------------------------+ --- 2,9 ---- | Automatic modification of standard classpath | +----------------------------------------------------------------------------+ | Bug #: 2611 Product: Ant | ! | Status: RESOLVED Version: 1.3 | ! | Resolution: FIXED Platform: Other | | Severity: Enhancement OS/Version: Other | | Priority: Other Component: Core | +----------------------------------------------------------------------------+ *************** *** 57,59 **** --- 57,83 ---- classpath in the shell. I know that a shell script can do this, but I don't like this because everything that can be done easily in the build.xml file should be there. In my opinion this avoids mixing of responsibilities. + + ------- Additional Comments From [EMAIL PROTECTED] 2001-08-12 01:34 ------- + If you want to avoid mixing responsibilities (and this is a good thing) + it makes perfect sense to define another classpath like you do, but that do + not include anything from java.class.path. (plus it is a dangerous thing + because paths in your classpath can be unresolved and that will fail if you + fork a jvm into another directory from Ant). + + I make a difference between what Ant needs to run and what my project needs to + run. My project might need xxx v2.x only while it is not supported by Ant but + only xxx v1.x. If you do a mix between Ant's classpath and yours, there, you + are mixing responsabilities. + + With complicated build it might happen that you may need ant.jar and + optional.jar and other things. A typical use in my case would be to use the + JProbe coverage task that runs Ant to perform all my unit tests in a single + JVM. This is an extreme case and I cannot rely on java.class.path because I + don't want to put the bazillion of jars that Ant needs to run all tasks and + that might possibly interfer with my tests. + + I honestly can't see where this is error prone. Unexplicit things are error + prone to me. + + Note: Make sure that <javac includeantruntime="no"...> is set when compiling.
