On Sun, 24 Mar 2002, stephan beal wrote: > On Sunday 24 March 2002 17:58 pm, [EMAIL PROTECTED] 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
