When you get a chance could you look at the patch for the below issue? I really would like to see this make into ant 1.8.3 release.


From: Vimil Saju <>
To: Ant Developers List <>
Sent: Friday, February 17, 2012 8:25 PM
Subject: Re: Regarding exec task

Hi Stefan,

I have attached a patch containing the changes I made to Execute java class. 
What I have basically done is move the code that initializes the CommandLauncher from the Execute class to to the CommandLauncher class. I have made CommandLauncher class public and all the subclasses of it public too.  I have added two static methods 
getVMLauncher and getShellLauncher to the CommandLauncher class. These methods take a Project object as parameter and check if a reference to an existing CommandLauncher is present in the project. If present then that instance is returned. Otherwise the method checks if a system property containing the name of the launcher class has been set. If so then an instance of that class is created and returned, otherwise the default launcher is returned. I have also added setVMLauncher and setShellLauncher methods that add reference to a given CommandLauncher instance to the project. 

I have modified the Execute class to use these two methods to get the reference of the CommandLauncher class. I have also created a CommanLauncherTask class similar to the PropertyHelperTask that takes an instance of any CommandLauncher class and adds a reference to it to the project.  

Could you take a look at the patch and let me know if any other changes need to be made.


From: Stefan Bodewig <>
Sent: Tuesday, February 14, 2012 5:45 AM
Subject: Re: Regarding exec task

On 2012-02-14, Vimil Saju wrote:

> Your help is very much appreciated. Would using a custom
> CommandLauncher make it possible for all the built-in ant tasks that
> support fork attribute to use it. 

Right now Execute uses a static CommandLauncher instance which is
initialize inside the static initializer ("class constructor").
CommandLauncher's responsibility is tro create the Process instances.

We don't have a way to make Execute use a different CommandLauncher, but
if there was (like using the ProcessHelper you describe) then it would
be used by all Execute instances - or we could make it so.

> I was thinking of an approach similar to how ant allows property
> expansion to be customized. By just adding our own custom
> PropertyHelper we can change how properties are expanded globally.  If
> we have something like that for processes too, it would be great.

> I'd like to write a patch for this if possible, but I'd like to know
> the best way to implement it, without breaking anything else.

That's great.

> My idea was to provide something like ProcessHelper class that can be
> stored as a reference in the project. The Execute class then calls
> this class to get an appropriate Process implementation.

I'm not sure about the name ProcessHelper when CommandLauncher is
already there, but I'm not good at names either.

One thing you must keep in mind is Execute may not have access to a
Project instance at all - it may know about one if setAntRun has been
used, but using that is somewhat optional.  Also some methods in Execute
are static and don't provide a Project.  There need to be usable
defaults for this case.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail: