> > The way tasks are handeled right now - and are expected to be handeled > in the future - would not allow abstract task classes. The static > factory method you propose doesn't fit into the way Ant works either.
I kept in mind where writing this that this approach doesn't completely fit to the current model. We can split this approach to the following points: 1) Behavior 2) Realization I think that proposed behavior better than current. Also this approach fits good for the tasks with multiple possible realizations. And task realization. It can be selected after behavior approval. I tried to avoid myself from bicycle reinventing and proposed the way like ORB class works. Yes, I do not want to argue about current taskdef realization. I found it very original and well thought-out. But for idlToJava-like taskdefs may be better to review the initial behavior and approaches? > I do agree your approach seems to be the most flexible one but would > need some changes to the Ant core. Thank you. Vitaly __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
