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 12:28:42 GMT
> From: Peter Donald []
> At 12:37 PM 5/23/01 +0100, Jose Alberto Fernandez wrote:
> >How do you find the classes used in your task's code.
> <classpath /> sub element.

whose, sub-element? <tasklib>? Or do you want me to declare the internal
dependencies of my task on every usage of it. :-P

> >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.
> yup - most of these will be moved into a "task-framework"
> section (think
> turbine to servlets is ant framework to ant API). We have to
> define a clean
> framework because that way we don't have some tasks relying
> on other tasks
> etc.

Let's not forget types or parameters. I will need to pass parameters of the
correct type for hich I will need tohe class definitions. I hope taks
writers do not have to use introspection all over their code.

> >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.
> The runtime deals with task proxies/TOM/etc and thus a task
> will not ever
> gain access to the other task instances.

How about the typed parameters of tasks. Do I need to loop thru hoops to
pass those?
Think how to pass <env> sub element programatically to a call to the <exec>
I do not want to have to write introspection for this.

> It's not that hard - have a look at all docs for tasks - they are
> relatively similar to each other. All we need is a simple DTD and then
> generation, indexing (including separation between one-liners
> etc) is done
> outside this. I believe it will actually reduce our workload
> rather than
> the reverse. You should know now I am lazy and wouldn't
> commit to doing
> something that would be more work ;]

Oh well, WE HAVE A VOLUNTEER!!! :-)

Jose Alberto

View raw message