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=25327>. 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=25327 Forked VMs != forking VM, breaking script portability ------- Additional Comments From [EMAIL PROTECTED] 2003-12-12 09:48 ------- OK, let's see (1) is Ant's default behavior. We shouldn't fiddle with it at all. If a build file specifies a different VM (by using <java>'s or <junit>'s vm attribute), it is going to break in Gump anyway as you have to know the absolute path to the VM. (2) there is an undocumented sun.boot.class.path system property, I've abused it. (3) has been rather simple. Note that cloning the VM in that way can not become Ant's default behavior for backwards compatibility reasons. For starters I've added cloneVm attributes to <java> and <junit> that enable copying of system properties and the bootclasspath. The later only if the user hasn't explicitly set a bootclasspath in the task (or build.sysclasspath is "only" as Ant's going to ignore the user specified path in that case). I've also added a system property build.clonevm that sets the default for said attributes to true instead of false (if build.clonevm == "true"). It has to be a system property to work right now - I'm not happy with this and that's why I don't close the report ATM, but we should first give it a try to see whether this improves the Axis situation. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
