ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject RE: DispatchTask
Date Fri, 04 Jun 2004 17:42:42 GMT
Subject:    RE: DispatchTask
From:       Dominique Devienne <DDevienne () lgc ! com>
Date:       2004-06-04 15:14:02

> public static void dispatchAction(String action, Task target) { ... }
> or 
> public static void dispatchAction(String action, Object target) { ... }
> to make it fully bean friendly.
> Then it's just the matter of writer
> execute() { TasktUtils.dispatchAction(_action, this); }
> And one can use any 'action' attribute one wants.
> When it can be avoided, I prefer to keep my single inheritance
> choices open. --DD

Nice idea.  I was thinking of the following:

Option 1: Allow task writer to just extend DispatchTask

interface IDispatchTask {
    public String getActionParameter();

abstract class DispatchTask extends Task implements IDispatchTask {
    public String getActionParameter() {
        return "action";
    public void setAction(String action) {...}
    public String getAction() {...}
    public final void execute() throws BuildException {
        //Nothing here - Ant's modified introspection would take care 
        //of executing the correct method

Option 2: Impelement IDispatchTask along similar lines of 
DispatchTask and still have Ant work out the details of 
which method to execute when.

Option 3: Let the user invoke the dispatcher manually
(your approach)

I'll try to implement it such that all these are possible...  
The neat thing with option 1 is that the user does not have 
to implement a dummy execute method to just dispatch stuff 
out.  But I do see your point of not wanting to extend if


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

View raw message