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 12:25:32 GMT
> From: Stefan Bodewig [] 
> On Fri, 2 Jul 2004, Jose Alberto Fernandez <>
> wrote:
> > Maybe Ant should provide its own delegation entry point 
> since this is 
> > a very common pattern of use.
> But maybe not something you want to expose.  Do you want to 
> see [ant] show up in the log instead of [subant]?

Not at all, the point is that when within a task that I write
I programatically use the functionality of other tasks, that
should not be visible to the user of my task which does not
need to know about how I implemented my task.

The user should only be aware about the tasks he expresses
in the buildfile and not about my implementation details.

> If so, a simple invocation of 
> getProject().registerThreadTask(Thread.currentThread(), ant) before
> ant.execute() would have done the trick.  Hmm,
> ant.setTaskName(getTaskName()) would solve the [ant] vs. 
> [subant] issue.

Why force every code writer to do all this stuff.
I guess my point is how to facilitate 3rd parties to write better
behaved tasks and to encourage reuse.

> > 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();
> The name looks the wrong way around since delegate is active 
> and really this is delegating to ant.

True, so maybe having in

  public void delegatedFrom(Task caller) {
      getProject().registerThreadTask(Thread.currentThread(), this);
	try {
	finally {
	    // Is there any need to unregister here?

Could something like this solve the issue with SubAnt in effectively
much less code?
Or is SubAnt's case more complicated.

> For some time we've been kicking around the idea of a utility 
> class for the delegation cases
>         // uses project.createTask, transfers task name and target ...
>         DelegatedTask ant = new DelegatedTask(this, "ant");
>         // uses IntrospectionHelper, also supports nested elements in
>         // some way
>         ant.setAttribute("buildfile", buildFile);
>         // registers itself as task responsible for output, calls
>         // execute and deregisters itself at the end
>         ant.execute();

This is fine, but you still need to support the case where one wants
to execute a specific Java class (i.e., not whatever was registered)
and achive the same thing. So one at least needs another constructor.
for DelegatedTask. How does one configures elements on this model?

In principle I am all for something that helps external people
write better code.

> > Maybe is is something for 1.7.
> At least not for 1.6.2 8-)
Definetly :-)

Jose Alberto

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

View raw message