> -----Original Message----- > From: Costin Manolache [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 24, 2003 2:47 PM > > >>> But the current one does not support adding other components like > >>> conditions, mappers, filters, and selectors. > >> > >> Does ant support this ? > > > > No, not currently in a pluggable manner. Isn't that the goal for > > antlib? > > To load collections of ant components ( whatever ant define as component > ). > Not to define new component types. > > Are you saying that all those nice filters, selectors, etc can only be > used > if loaded by antlib ? > You can define a task with <taskdef> in a regular ant file - why wouldn't > you be able to define the condition without using an antlib ?
Because: 1) Having an <xyzdef> for every single one adds new elements for nothing, and is not extensible to custom types (like <buildpath>) to define its own new typed role/interface (<buildpathresolver>). 2) <antlib> supercedes <taskdef>/<typedef> (which remain for backward compatibility), adding extensibility to other types (within Ant or not)! Why are you getting hang on <antlib> per se? What's bad about having an in-build-file <antlib>? It's not worse than a <taskdef>, and better because extensible to new roles/types/interfaces/beans, whatever! The point being that AntLib doesn't define new component types, it allows *me* and *every other* build file writer to define my own new component types and/or implementation of existing component types. I don't care how you want to implement it! I want the functionality AntLib provides ASAP, so if you don't provide a 'better' proposal that solves the same issue, namely being able to plug in not just types/tasks to Ant which are configured like regular types/tasks, then your -1 squarely goes against my *need*, and the needs of quite a few others; a need I hope you agree is important... --DD
