ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: Exporting a Project Instance
Date Sun, 24 Mar 2002 22:59:01 GMT
On Sun, 24 Mar 2002, stephan beal wrote:

> On Sunday 24 March 2002 17:58 pm, costinm@covalent.net wrote:
> > Step back a bit - what do we gain by making it an interface ? Multiple
> > inheritance ? One more class in the core, just to make the object model a
> > bit more complex ?
> 
> The main reason i thought of it was that some objects which are doing task 
> jobs don't subclass task, and must therefor be proxied. RecorderEntery comes 
> to mind.

Again, you don't have to extend Task - just create your task without 
extending Task or any other ant interface, and TaskAdapter will take care 
of it.

There is only one reason to extend Task ( or use ant specific interfaces) 
- to get access to Project and logging. There are solutions for this - 
like using per thread data ( like Axis, and few other projects ), and 
probably using commons-logging for logging. 


> > As long as you expect all tasks to extend AbstractTask, there's
> > no point of defining an interface. 
> 
> Good point. The main reason would be to avoid proxying, but proxying is 
> neither evil nor terribly much work, so it's not a big deal.

If a task does need Project and access to ant classes - it'll be probably 
cleaner if you use delegation ( == proxying ). If it is a generic bean -
just extend what you want and use the TaskAdapter. 

One of the main benefits of ant is that it has minimal pain level for 
common things - just a bean with an execute() method in 90% of the cases.


Costin


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message