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!?!? 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. --DD -----Original Message----- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 23, 2003 10:12 AM To: [EMAIL PROTECTED] 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.
