ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Duncan Davidson" <>
Subject Re: Tasks containing other tasks (was: Subtasks within tasks)
Date Mon, 28 Feb 2000 05:26:43 GMT
> If we want ANT to really be able to succeed in the large as well as the
> small
> we will need will eventually need some way to define new tasks by
> composing
> existing tasks. In any type of composition we will need some way pick
> between alternatives.

There's a limit at which I'd personally like to see Ant go to. Yes, at some
point, the simple model it uses will run out of steam. But that's a very
large point. The JDK is increadibly huge, but I'm pretty sure that I could
build it with a modified javac taskdef that split the total number of
classes to compile into manageably sized chunks. Everything else about that
build would require memory and some processor speed. So at least to that
level I disagree with you that we'll have to put any amount of turing
completeness into ant to manage larger projects.

What would help is a way of building antfiles that was GUI based so that you
aren't stuck typing in XML. A simple Jtree based GUI along with addTask,
removeTask buttons would go a ways there.

> 1) A way to define new tasks by naming other tasks:
> <taskdef .... >
>   <task1.../>
>   <task2...> ... <task2>
> <taskdef>

So if you did that, how do you propose the reflection of properties would
work? Especially if there was a namespace collision. In addition, even if
that weren't a problem, I don't see what you've done that you can't do with
with calling task1, task2 in order. It's not quite like chemistry where 2xH
+ 0 = something different. :)

> 2) Something like lisp's mapcar so that one can apply
> the same task to a sequence of values. So one can
> say things like apply this tasks to all this values.
> This is declarative in the sense that there is no order
> involved in this application, in principle one could
> apply the tasks in parallel or backwards or whatever.

Reasonably interesting. But I don't think that the relative complexity of
adding such a feature would really be worth it when it would be just as easy
to call out what you needed.


James Duncan Davidson                     
Java + XML / Portable Code + Portable Data                 !try; do();

View raw message