ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: [DISC] details of task library concept
Date Wed, 23 May 2001 23:41:38 GMT
Jose Alberto,

Let me firstly say that we are not trying to prevent users from reusing
code. We are trying to correctly manage the classpaths/classloaders in Ant-2
properly. The Ant-1 approach is to place all jars in ANT_HOME/lib into the
classpath before starting Ant. I think there are problems with that approach
since those classes share classes with all other tasks, with Ant, with Ant's
JAXP parser. There have been problems caused by this approach, especially in
the JAXP area.

> -----Original Message-----
> From: Jose Alberto Fernandez []
> Sent: Thursday, 24 May 2001 6:14 AM
> To:
> Subject: RE: [DISC] details of task library concept
> I agree completely with you here. createTask() is the wrong way of doing
> things.
> 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
> exists,
> and the application of the <delete> task on those thing that do not exist
> anymore.

OK, lets say the tasks you want are in the corefile.tsk jar provided with
Ant. I believe you will just have to put a classpath reference into your
jar, deploy into Ant's task area and away you go. You will automatically
have access to these classes in your task. I haven't tried that but I will

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

You are assuming that you can create a Copy task. Even in Ant-1 it is
difficult to properly create a task in isolation. Did you set the Project,
the tasktype, the task name, the location, etc. This will be even more
difficult in Ant-2 since we don't want to open up the whole core to the

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

As I have said above this is not what we are trying to do and I believe we
should be able to do what you want as described above. However it is better,
IMHO, to provide services that can be reused by many tasks rather than
trying to reuse tasks directly.

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

In Ant-2 I do not expect any tasks to be invoking services in the core
through other task's interfaces. This is not that common in Ant-1 and is the
wrong approach anyway, IMHO.

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

I'm not sure how that is going to work. Show me the syntax you see. We are
talking about the automatic deployment of tasks here, right? The classpath
can be specified as a relative classpath in the Jar's manifest.

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


View raw message