ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [DISC] details of task library concept
Date Wed, 23 May 2001 20:13:51 GMT
> From: Conor MacNeill []
> >
> > How do you find the classes used in your task's code. Today
> there are
> plenty
> > of tasks that make calls or inherit from the classes of other tasks:
> <java>
> > uses the code from <exec> when fork="yes". And plenty more examples.
> There
> > is no reason to forbid a task developer from calling in their tasks,
> other
> > tasks provided in other libraries. You will have to be able
> to especify
> > where these other classes are when you load the classes for
> the new task,
> > and not when you configure the task.
> >
> Jose, I believe that many of these needs will be met by
> providing java and
> external command execution *services* within the core. In
> other words I
> don't think a task should have to create another task to get at these
> services. The practice in Ant-1 of casting the result of
> Project.createTask() to specific task types is plainly
> dangerous in the
> face of the user's ability to redefine the tasks.

I agree completely with you here. createTask() is the wrong way of doing
And that was exactly my point. For example, I was planning on writing a task
that syncronizes two directories. That is it make certain that both ar
exactly the same.
Well this is just an application of the <copy> task (to pudate anything that
and the application of the <delete> task on those thing that do not exist

The way to write (in Java) this task. Is to is to internally create an
instance of the class defining the Copy task (not using createTask) but
doing "new Copy()" which is the class I want. fill up the parameters for it,
using its well known API. And calling its exec() method which is also well

Here the users ability to rename tasks, has nothing to do witht the issue
because I am working at the Java level. But is I cannot instantiate the
class because of the classpath, I am screwed (forgive my language) or I need
to ship a copy of the Copy class as part of my jar and then only God will
know the inconsistencies we can ge into.

All because we are actively trying to forbid people on using the code
written by others (so much for the concept of reusability and not
reinventing the wheel).

> If you were to be able to create Tasks at will, and I'm not
> sure that will
> be the case in Ant-2*, then I believe you should use the same
> contract the
> Ant core must use in dealing with such tasks - the Task interface (and
> reflection).You should not cast to a particular subclass. If
> you adhere to
> these rules, then you should be able to manipulate other
> tasks regardless
> of what classloader has been used to load them since the Task
> interface
> itself will come though the loader used to load the Ant core.

I want to use the Java class directly, I do not want to make people spend
their afternoon  writing catching statements to fence about exception in
reflection. This just creates obscure and unreadable code.

Take a look at half of the tasks in Ant-1 and think about how they would
look like if every individual task had to reinvent everything or use
reflection to be able to access the capabilities already offerend by other
tasks. That is what you are asking for library code and there is  no reason
whatsoever to treat core tasks any different.

The only thing I am asking is for tasklibs to be able to specify a classpath
with dependencies and such.

> If you choose to subclass another task, then that is OK, it
> just means that
> the base class will be loaded twice, once of its own task in its
> classloader and once in you task's classloader. The core will
> not consider
> them to be the same class and nor should you.

The point is that to find it, first we need to have a way to specify where
it is.

Jose Alberto

> Conor
> (*)
> Your ability to create a task in Ant-2 will require that class to be
> initialized with a TaskContext and it may be that a Task
> itself does not
> have sufficient information to create such a context.

View raw message