ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject RE: antlib
Date Fri, 25 Apr 2003 14:02:11 GMT
Jose Alberto Fernandez wrote:

> 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.

Fine - but do this in core, not in antlib.

Antlib needs to load whatever ant supports. Not to define new things. 

I don't have any problem with polymorphism ( or roles ). Nobody said they
shouldn't be added. My only comment is that the implementation of
polymorphism shouldn't be tied with antlib, and I would preffer a solution
that would simplify the core - i.e. interfaces or something like that, that 
would allow us to treat all components as components at the low level.

An unified way to treat all the sub-types should be defined and implemented 
as part of the core. 

We can wait with antlib ( the part that loads whatever-things-ant-supports)
until polymorphism is defined, but I would preffer having antlib included
in ant sooner.

Costin


> 
> 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:peter.reilly@corvil.com]
>> 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 <cmanolache@yahoo.com> 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: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>> 
>>



Mime
View raw message