ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: antlib
Date Wed, 23 Apr 2003 16:04:00 GMT


> From: Dominique Devienne []
> One comment about roles: Roles are fine, but roles are just 
> strings... If
> everything is defined as a component at a low level, then 
> they can be easily
> introspected to find out what interfaces components 
> implement. For example,
> why would I have to say:
> <define classname="a.b.C" name="..." role="selector"/>
> when class a.b.C does implement FileSelector! The role is 
> implicit thanks to
> the type of the class itself. I suspect there will be more 
> cases where a
> role maps directly to a single given interface than to an 
> arbitrary bean,
> which is the only case where a role string needs to be specified!?!?

Good observation. But in the proposal, roles ARE NOT JUST STRINGS.
Roles are interfaces with an optional "adaptor" class. So all what you are saying
more or less applies already.

I am not too keen about automatic discovery of roles because I do not have
a full feeling for it, it could come in the future.

> So an AntLib system that forces to spell out (string) roles in an XML
> descriptor (which I also prefer over the Manifest) when the 
> defined class
> itself already embeds this info in it own type will be 
> cumbersome at best.

Remember that data-types have no restriction on implementing anything.
Given BC you need to be able to support it. This is why I had to add this
concept of Adaptor to a Role, so that we could treat everything in a unified
standard way.

> --DD
> -----Original Message-----
> From: Stefan Bodewig [] 
> Sent: Wednesday, April 23, 2003 10:12 AM
> To:
> Subject: Re: antlib
> >> With that, do we really need separate <task> and <data-type> in
> >> <antlib> or are they just special cases of roles?
> > 
> > They should be.
> So if they are just roles, why treat them in a different way than
> other roles?  Why a <task> element?
> <define classname="..." name="..." role="task"/>
> could do the same and be more consistent.  I don't have a strong
> feeling here, just trying to find my way through the ideas without
> having to read the code ;-)
> Maybe something could even be in different roles at the same time?
> See available, checksum or uptodate for things that are tasks and
> conditions in one.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message