ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Ant in the future
Date Mon, 18 Feb 2002 21:28:50 GMT
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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message