> From: Costin Manolache [mailto:[EMAIL PROTECTED] > > > At the low level - i.e. all are components, we just create and define > the components. > > If they are used in one role or another - or how the role is > associated > ( patterns like "has an execute() method" or interfaces ) - it really > shouldn't matter when you create the component. >
Somehow you have to be able to say if your component can be used as a mapper or a condition or a selector or a fileset or a path or a task. Or someting else that is defined be some other component provided by someone else (e.g., <ejbjar> subelements). If you ask how we manage today with only two roles (task and datatype) is that we do not have any way to say "this new class of mine can be use with this element name wherever a mapper can be used". What we do is on every usage we say "use special mapper defined by class XYZ" and we have yet a different syntax for conditions and for each little thing". > I'm also not convinced on the XML descriptor - I would rather keep > a properties file ( if we operate in terms of "project > components" - that > becomes very easy ), or at least standard manifests. It is > quite easy to > just use the normal META-INF/Manifest, and add a "Ant-Role: > Task" attribute > to the Name: entry for a particular class. ( assuming we > decide not to do > "everything is a project component" ). > Manifests and properties files give you such a limited language such little expandability for future features. Ant users are already writing XML as a matter of fact, it should not scare any of use at this point (mostly if we can offer tools to do any conversome work for them). For what I here already people will want versioning, which probably means dependencies. Not even today do we have one properties file for the core, we have two (tasks and types) because we have no way to give that information in one file. Take a look at the xml that was used in the proposal it was very simple and very ANT looking. It should not cause any traumas :-) Jose Alberto
