[EMAIL PROTECTED] wrote:
+ * add a <antfork> task that runs a completely new ant
process, with different env, maybe even JDK. Sometimes people
need this; running forrest builds is just one example. We'd
use <java> to set it up.
I would prefer enhancing <ant> with fork and jvm attribute, like <java>.
the reason for making it separate was to lower peoples expectations
about high tightly things are integrated/ <ant> will pass down
references, system state, current proxy settings, defined presets and
macros. the current listener/logger gets results back.
an <antfork> run wouldnt have naything other than proprety propagation,
unless you
-write a wire format to send serialized build log events over the wire
(not that bad, to come to think of it...)
-make all datatypes serializable. no, we dont want to go there.
accordingly, you wouldn't have any way in <antfork> to declare the
datatypes to go down. more stuff to point at the JVM, the base dir, task
and target, maybe even the failonerror value.
Integrating logging is certainly tricky. we could do it with a special
logger in the forked vm that fed serialized build log events over
stdout, and something in the main process that catches that and relays
it to the local logger. This would let forking work better. It would
also be a basis for anyone trying to run ant across hosts ;)
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
