Hello, I've been working on some enhancements to the ExecTask and Execute classes so it's now possible to execute a process detached from Ant using the <exec> task. To support this behavior, I've added a waitFor attribute which defaults to true for the existing behavior but when set to false, starts the new process detached from Ant. This part seems to be working fine on NT and Solaris.
What I haven't implemented yet is output redirection. As I see it, there are two viable ways of handling output from the detached process: 1. Write to a file. To handle this, I'm planning on making the output attribute of <exec> pass through as a setting to Execute where it will run antRun -o output-file ... The same would apply for Windows antRun.bat. This functionality is a requirement so output from commands can be directed somewhere else than the bit bucket (especially on NT). 2. Start a new window in which the application runs. For this, I'm thinking about new scripts antWinRun/.bat which on Windows runs "start" and on UNIX, runs xterm, dtterm, KDE konsole, etc. configurable through an exported environment variable ANT_WINTYPE. Ant itself wouldn't know or care about this as it would be set before starting Ant and passed through in the environment. However, it would be simpler from the Java side of things to enhance the existing antRun scripts so a -w argument would indicate running in a new window. To support this, the <exec> tag would need a new attribute "inwindow" which would then be passed through to the Execute class indicating the antWinRun or antRun -w script should be executed. Right now, I have this working in the sense that given the right command for the OS you're on, you can run it in a new window. I'd just like to make it work cross platform in a fairly transparent manner. I haven't yet looked at the <java> task to see what it will take to implement at least #1 above but plan to if I have time. So before I do much more, I'd like some feedback if this is something that would be appropriate for 1.3. Also, I'm not sure I like the attribute waitFor. Detach or noWait sound better to me. There was some talk about getting multithreading support implemented in 1.3. If this were to happen, I'd want to use an attribute name that wouldn't be confused with anything thread related. Thanks for your input, -Bill Burton
