Peter, this is exactly my point. For every new thingy that we add we now need to go and modify IntrospectionHelper or something to make special allowances for it.
It is bloating the core like mad and in my opinion it is crazy. We need a unified way to treat this things no matter what the things are. Ant's engine core should not need to know anything about anything. In an ideal world, we should have an engine core with no reference to any task/type or its implementing classes and a core-antlib which provides the classes and definintions for all the task/types/conditions/selectors/mappers that define core java. We could even have separate release cycles for it. THAT is the potential for antlib (and it is not polimorphish). Jose Alberto > -----Original Message----- > From: peter reilly [mailto:[EMAIL PROTECTED] > Sent: 25 April 2003 10:30 > To: Ant Developers List > Subject: Re: antlib > > > On Friday 25 April 2003 08:31, Stefan Bodewig wrote: > > On Thu, 24 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote: > > > Look - adding "roles" concept to ant, and adding antlib are 2 > > > separate issues. > +1 > > > > I tend to agree - that's why I proposed to get antlib into the main > > trunk with support for types and tasks only. At least for starters. > > > > If you want a custom mapper you can do so right now with a data type > > and refid. The same is not true for filter readers, conditions or > > selectors. But I feel that enabling that would inevitably > lead us to > > Not quite true for filter readers. > > In CVS HEAD, FilterChain has a currently (deliberate) > undocumented feature of > implementing DynamicConfigurator. The implementation looks up the > name in the types and if present and if the bean implements > ChainableReader > it is used as a ChainableReader. > > This is used to support ScriptFilter. Script reader is an optional > ChainableReader which depends on the presence of BSF and thus cannot > be implemented in the same way as the other built-in ChainableReaders. > > > the more general polymorphism discussion and this is what I > wanted to > > avoid 8-). > > I have implemented a generalization of FilterChain's > usage of DynamicConfigurator in IntrospectionHelper. > This extends the introspection support to include methods of the form: > > public void dynamicElement(<type> name); > > So in my local ant build the relavant part of FilterChain.java is > > public void dynamicElement(ChainableReader reader) { > filterReaders.addElement(reader); > } > > and of ConditionBase.java > > public void dynamicElement(Condition condition) { > conditions.addElement(condition); > } > > -------------------------------------------------------- > > As regards using roles: > (note: Roles in the antlib proposal are not completely implemented,ie. > there is no condition, mapper or filter implementation so > my comments may be correct). > > Roles in the proposal provide three features: > > 1) they provide a way of limiting the scope of the tag. I assume that > this is meant to be used by introspection in the same way as > the dynamicElement method above. > 2) As a consequence of 1), the same identifier by be used to > point to different classes. > 3) they provide an optional adaptor to allow classes that do > not support > a requred interface. > > These features may be implemented in different ways, for example: > > typedef could be extended to have an implements attribute: > > <typedef name="and" classname="o.a.t.ant.taskdefs.conditions.And" > implements="o.a.t.ant.taskdefs.conditions.Condition"/> > > "and" may then only be used in beans that have the method: > public void dynamicElement(Condition condition) > > if the class did not implement the condition, a proxy class > could be defined: > <typedef name="diskfull" classname="acme.disk.DiskFull" > implements="o.a.t.ant.taskdefs.conditions.Condition" > proxy="acme.ant.ConditionAdaptor"/> > > or one could have a class that defines adaptors: > a new task may define adaptors: > > <adaptor classname="o.a.t.ant.taskdefs.conditions.Condition" > proxy="acme.ant.ConditionAdaptor"/> > > -------------------------------------------------------- > > My feeling is that roles are not needed to support dynamic conditions, > filters ..., > in fact I do not think that typedef is needed: > > <loadclasses classpathref="${acme.ant.jars}"/> > > <condition property="disk.danger.level"> > <acme.disk.DiskFull percent="70" filesystem="/tmp"/> > </condition> > > I see typedef/taskdef as providing alaises for java beans. > > Peter. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
