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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
