On Sat, 9 Mar 2002, Jose Alberto Fernandez wrote: > Ok, I should sound like a broken record by now, but how do you plan to solve > the case of data-types that DO NOT EXTEND from o.a.t.ant.types.DataType?
I allways have problems explaining - I answered this several times before, it is a non-issue - we already do that for tasks that do not extend o.a.t.ant.Task, it works reasonably well ( I have few dozen tasks of this kind ). All you need is an adapter - for tasks we use TaskAdapter, something similar will be done for DataType. The factory returns either a Task or a DataType. If the component implements the interface, no problem. If not - we return a TaskAdapter or DataTypeAdapter, implementing the interface and wrapping the non-ant object. By extending the use of RuntimeConfigurable, the adapter can even implement arbitrary policies for 'adaptation' - you can adapt an object that doesn't even follow ant patterns of setters, or execute(). Sorry for not beeing very clear in my explainations. > > For consistency, we should have all tasks use the RuntimeConfigurable, > > even if they are top level - but that's again a change in the > > xml processor, can be done outside. > > Somebody else mentioned that maybe we should be using UnknownElement or > NestedElement all the way during construction and delay the actual expansion > to just before usage (or when someone actually tries to access the Task out > of the Target. I would consider UnknownElement and NestedElement more of an internal for the helper. But if we need to - we can use them as well. > The only special case is with "id" references that would have to be resolved > when they > are used, (if not resolved yet). Doesn't seem like a huge problem. > If we could a consensus on how to do that we could reduce ProjectHelper cruft > by at least > 80% (at least in the version in <antlib> proposal) and we would finish with a > completely > regular set of rules for constructing and evaluating the tree. And all that > could be done in a real > backward compatible way. And yes we could get rid of all those invalidation > tables in the code. It seems 'consensus' is not very easy - that's why making the core more flexible ( by adding hooks and modularizing ) is so important. If we add the right hooks, the consensus will not matter that much, any solution will be implementable without requiring consensus ( as an external plugin ), and if successful it'll be much easier to make it part of the core. And will allow the various ant2 features to be implemented and used with ant1 - so we can have a gradual transition, decide which implementations we want and which features are indeed usefull. And when we have everything, we can bump the version number and remove deprecated stuff. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
