Dominique Devienne wrote: > I don't understand why you need to load custom tasks/types before the Core > tasks/types. The current mechanism for loading them seems OK to me > (awaiting <antlib> for a better mechanism though).
I don't know about his use case - for me it's saving the 4 seconds on startup and avoiding a lot of ugly code dealing with reloading optional tasks in a different loader. I use some code that allows adding junit.jar ( or other dependencies ) inside build.xml ( instead of ant.home/lib ), and this works by reloading junit and similar tasks with a different loader. Lazy loading would avoid this. In general, there is no reason to not allow the core tasks to be redefined. > I personally believe we need a mechanism to load and configure other types > of Ant extension points (Mappers, Conditions, Selectors, Filters, > XmlCatalog resolvers, and even custom extension points) similarly to > what's currently possible for tasks/types, which is good enough for now. I think we do have one already :-) Any task can call methods in Project and core and add whatever hooks it wants. For example in order to plug a particular antlib impl or a PropertyHelper you just have a regular task that calls the add method. It is easy to add "magic" - i.e. if a task implement one of the hooks interfaces we can add it automatically, but it's more flexible and clean to let the task control that ( apache2 modules follow the same model, there is a single "module" that can add itself to any hook ). > By that I mean ways to configure the custom class using complex Ant > objects represented as nested XML elements, share classloader, and have > access to the Project reference. I think we're on the same page. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
