This explains why some of my ooold <foreach/> tasks
produced funny output. At the time I did not care about it.
I agree with DD that the current arrangement (dumping the
work on the caller) is not clean or nice. Calling Ant.perform()
is not right either.
Maybe Ant should provide its own delegation entry point since this
is a very common pattern of use. So, a task that wants
to delegate its work to Ant, will call something like:
Ant ant = new Ant(...);
//Configure it ...
ant.delegate(this); // was ant.execute();
So eventhough the responsibility of what to call is still in the caller
all the infrastructure framework is done by the Ant class.
Does this makes any sense?
Is this something common in many Tasks used for delegation?
I.e., shall this entrypoint be provided by the basic Task implementation
public void Task.delegate(Task caller) {
// Default implementation just calls execute
execute();
}
And tell people to use Task.delegate() when calling a task inside
another.
Maybe is is something for 1.7.
Jose Alberto
> -----Original Message-----
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: 02 July 2004 10:36
> To: 'Stefan Bodewig '; '[EMAIL PROTECTED] '
> Subject: RE: SubAnt output
>
>
> -----Original Message-----
> From: Stefan Bodewig
>
> On Fri, 2 Jul 2004, Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> > [DD] What if instead of adding all these methods, we called [DD]
> > ant.perform() instead of ant.execute()!? [DD] perform()
> fires the the
> > taskStarted event, so would that be [DD] enough? Would be a
> lot less
> > code, no?
>
> It would help with the I/O "problem" but at the same time
> cause a task started event for <ant> which would lead to some
> visible output. This would make the design choice of
> delegating to Ant use visible and even be confusing to users
> (which <ant> task? I never started an <ant> task).
>
> [DD] Hmmm, I see your point. I personnally don't mind
> exposing this [DD] aspect of the implementation of SubAnt,
> especially when in fact [DD] a lot of tools look for the
> execution of Ant to find out about [DD] subbuilds. This point
> is kind of moot with your addition of [DD] SubBuildListener though.
>
> [DD] I still think that the fact that SubAnt must be aware of
> these [DD] I/O issues is not very clean, since not fully
> encapsulated in [DD] Ant itself. It would be better if Ant
> explicitly pushed its [DD] new Project on Ant's I/O subsystem
> to associate it to the current [DD] thread, popping it in a
> finally, and not have to make SubAnt [DD] or any task that
> internally uses an Ant instance (I have several!) [DD]
> explicitly deal with it.
>
> [DD] I hope I'm making sense. Thanks, --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
