ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: Initial impressions of ant...
Date Tue, 24 Jul 2001 03:20:38 GMT
> From: []
> Sent: Tuesday, 24 July 2001 11:53 AM
> To:
> Subject: RE: Initial impressions of ant...
> On Tue, 24 Jul 2001, Conor MacNeill wrote:
> > > From: Paul Kilroy []
> > >
> > > I'm in the process of migrating our project to ant, everything
> > > went smoothly
> > > except the following:
> > >
> > > 1)I initially tried to write a task that used (w/o
> inheritance) the Java
> > > task. This was too hard IMO. Had to set the project on the
> Java task, but
> > > the method was package scoped, so I had to play some silly games.
> >
> > You should probably use project.createTask("java"). This will properly
> > initialise the Task. I guess it is a bit like servlets in a servlet
> > container. You can't just create them and hope they will be
> connected into
> > the container's infrastructure. It is the same in Ant.
> That doesn't mean ant should do the same :-)

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.

> 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.

> ( I know this "framework/simple build tool and nothing else/collection of
> tasks/etc" is a sensitive issue, don't want to reopen it )
> > that guarantee should be made in the services not the tasks
> layered on these
> > services. We need to control the scope of the API Ant makes available to
> > task writers to make upgrading Ant manageable.
> +1
> And also makes integrating/reusing ant tasks in other places much easier.
> I think the big collection of usefull tasks ( as components ) is as
> important as the "build tool" functionality.

I think that is the approach Peter has championed, and, using the
TaskContext as the interface contract, I too think it is a good way to go.

View raw message