ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: SubAnt output
Date Fri, 02 Jul 2004 10:24:41 GMT
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

And tell people to use Task.delegate() when calling a task inside

Maybe is is something for 1.7.

Jose Alberto

> -----Original Message-----
> From: Dominique Devienne [] 
> Sent: 02 July 2004 10:36
> To: 'Stefan Bodewig '; ' '
> Subject: RE: SubAnt output
> -----Original Message-----
> From: Stefan Bodewig
> On Fri, 2 Jul 2004, Dominique Devienne <> 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:
> For additional commands, e-mail:

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

View raw message