On Tue, 19 Feb 2002, Peter Donald wrote: > > This is similar with 'pluggable task engine'. I assume the 'task engine' > > is the code in Project that resovles target deps and calls the > > tasks. > > Nope the task engine was simply "Execute a task I give you in this > environment". project engine was "Execute a project I give you in this > environment"
"Execute a task when I give you this env." seems to be working fine wihout changes in the core ( for most of the tasks that I used ). ( well, it sucks as API - you have to create a Project, set the logger, set the project on the task, etc ). Making things easier would be nice, of course - but besides improving the defaults I don't have any problem with that right now. > > Refactoring the code ( with the current API preserved, wrapping > > the new class ) seem to me like a decent ( and similar ) proposal, > > that would be benefical for ant. > > > > Is anything that I'm missing here ? > > Try it. I will await patches but I don't think it is as easy as you say nor > will it be as easy as you think to get it into the core. ProjectHelper is called by 4-5 classes, but most of the calls are static wrappers for introspection or project methods. The only one that matters is configureProject(), and adding an if() at the beggining and either a system property or a static proxy seems trivial. I agree, refactoring the parsing code and adding the namespace support and making it axis-style extensible is not easy, but making it pluggable is quite trivial. I don't want to have the new reader into the core - but in commons-sandbox, I just need a hook to be able to use it. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
