ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: [DISC] details of task library concept
Date Thu, 24 May 2001 02:26:45 GMT
At 09:13 PM 5/23/01 +0100, Jose Alberto Fernandez wrote:
>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.
>
>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.

I don't believe we are making any guarentees about stability of java apis
for tasks. we do make guarentees for the TOM though so it would be better
to use that directly. So something like

copyTask = new Configuration();
copyTask.setAttribute("file","myfile");
copyTask.setAttribute("todir","mydir/");

taskEngine.execute( copyTask, getLogger(), getContext() );

will be the way to do it. However in all likelihood we will wrap this up so
you just have to do 

copyTask = newTask();
copyTask.setAttribute("file","myfile");
copyTask.setAttribute("todir","mydir/");

executeTask( copyTask );

>Here the users ability to rename tasks, has nothing to do witht the issue
>because I am working at the Java level. 

at the java level we offer no guarentees (ie you are on your own).

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

yup.

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

nope. Reusability is increased by this. A clear interface that is actively
controlled increases reusability (basic tenet of reusability is low coupling).

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

we won't need to use for it at all. See above.

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

no idea what you are talking about here. Except for inheritance graphs (ie
war/jar/zip) there is little need for direct references to other tasks. The
only reason it is used in ant1 is because we don't have proxy task objects.

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

and it has been said a number of times that will be present - we are
however not going to support any non-TOM/java level API I don't believe
(except in framework).

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message