ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Initial impressions of ant...
Date Tue, 24 Jul 2001 05:50:44 GMT
On Tue, 24 Jul 2001, Conor MacNeill wrote:

> OK. fair view. In Ant 1.x, it is, however, probably not practical. The tasks
> are not cleanly separated from the core in the current implementation. If
> you want to use a particular Task, you are going to need to bring along
> Project, etc, etc. It is highly coupled, unfortunately.
> The solution we have considered for Ant2, is to define the interface between
> a task and the core - through a TaskContext. It is similar to Servlet
> concepts and I think it is useful. If you want to use Tasks in another
> context, that will be fine but you are going to need to provide that
> interface to provide the Tasks with the services they require. That will
> decouple the Task from its environment.

> > Probably that's something for ant2, but beeing able to use the tasks as
> > standalone beans in normal java code would be extremely usefull. Even in
> > the current ant, it can be done just by making few methods public and
> > decoupling a bit.
> The same concept could be provided in the current Ant, true enough. It would
> be a "backward compatiblity" challenge.

Most work will be to convert the tasks to the new interface, and to
"convert" people who write tasks.

IMHO the sooner the TaskContext interface is added, the easier will be to
do the transition. I know this is a big step and ant2 is the "normal"
place to do it, but trying few small things and adding few interfaces now
could help a lot.

> > Example: javac task is something very usefull outside ant ( jasper, xalan,
> > etc), and having it available ( with Project acting as an execution
> > context - i.e. handle logging, etc ) will give people a more "consistent"
> > experience with different apache projects ( same way to specify "use
> > jikes" or "generate emacs errors ).
> That is reasonable. Should the Ant task be the way to package up such
> services? Perhaps. then again, you could packge up the service and build an
> ant task around it.

Yes, that's what always do - I create the beans ( with no dependency on
ant ), then use the task adapter.

I don't use any ant service in my code ( well, sometimes I feel a need for
logging and for a hashtable like refIds, but it's easy to do that
without using ant, but separate tools ).

In other words - it is possible to write ant tasks without any dependency
on ant. Probably not all tasks - but many.

The Task interface is good  to avoid a reflection ( when calling
execute() ), but that's a small gain giving the number of reflection calls
to set properties, etc.


View raw message