Hello,
A number of people have asked for this kind of detached or background
starting of an executable. I wrote generic support for this but didn't
have it sufficiently tested before code freeze hit for the 1.3 release.
What I've implemented allows the <exec> task (and it's subclasses) to run
an executable detached in the background either redirecting the output to
a file or opening a new window. This is done in a platform-independent
manner (at least for Windows 9x/NT/2K and UNIX). The <exec> task supports
four new attributes and one modified one:
detach=true|false - if true, runs process detached in the background
output=file-name - modified so this works when detach=true
inwindow=true|false - if true, runs process detached in a new window.
On Windows OS's opens a new console window. On UNIX, can run
xterm,
CDE dtterm, KDE konsole or gnome-terminal (and I plan to add
screen).
The type of window and geometry can be selected by exporting
environment variables before running Ant.
windowtitle="title of new window" - Title to display in new window
when
the inwindow attribute is set to true.
usescript=true|false - When true, will always use the script launcher
causing the antRun script to be called to execute the command.
This
works even if Ant is running in a 1.3 JVM.
Something I may consider is writing new versions of Execute.runCommand
that will support detached with output or detached in a window. This will
make it easier for other tasks to use this functionality.
As some of my changes conflict with at least one recently posted patch,
I'll post a patch once things settle down with the 1.3 release. In the
meantime, if anyone has comments on this functionality, I'm open to any
input.
-Bill Burton
John Brush wrote:
>
> I am using Ant to do some development with weblogic server, and I ran into
> some problems trying to get it to return after spawning a new process/window
> at the command line (Windows 2000). A quick scan of this mail list showed me
> I was not the first person to run into this problem. Unfortunatly I don't
> have the time to research this in more detail (got a deadline end of Feb.),
> but the attached patch has at least solved my problem. Perhaps it can serve
> as a basis for something along these lines in a future release.
<snip/>