ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <jofer...@us.oracle.com>
Subject Re: Tasks containing other tasks (was: Subtasks within tasks)
Date Mon, 28 Feb 2000 20:25:16 GMT
James Duncan Davidson wrote:

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

My idea of in the large, was not reffering to the amount of files to Javac but
to the amount of tasks required of a large project in general. I can agree that
if the goal is just Java we may not need too much more because we have
made the javac task so powerful that overcomes the shortfalls of ant as it is
today.

But, could we use and for building Apache (the webserver?), a tool for that
would
have to take care of a more broad set of issued. My point is that ant has the
potential
to break the current java "glass ceilling". And being a more declarative way to
define
builds that what we have with MAKE today which I agree is quite a monster.

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

GUIs are fine, but not the end of everything.

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

Hey, I do not have all the answers :) at this point I am just dropping ideas for

we all to consider.

With respect to the second part of your comment, I just have
to mention that had such an attitude prevailed we would be writing assembly
language.
Do you believe in code reuse? modularity? If someone composes a task is because
he plans to perform the same group of operations over and over and it makes more
sense
writing it just once.

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

This will allow for something more declarative than coding than for loops.
The idea here would be to be able to say "apply to all files include...
exclude...",
and things like that. Notice that today we have that functionality only at
specific taskdefs but not a general facility available to tasks. So we could
have
something like:

Here the property "file" is set to the value of the file on each application.
<apply2files include="...." exclude="...." >
   <task1  param="${file}" ....>
   <task2 ......>
</apply2files>


>
> .duncan
>
> ----------------------------------------------------------------------
> James Duncan Davidson                               duncan@eng.sun.com
> Java + XML / Portable Code + Portable Data                 !try; do();

--
  ------------------------------------------------------------------------
 Jose Alberto Fernandez               500 Oracle Parkway, M/S 9op4
 Development Manager                  Redwood Shores, CA 94065
 ORACLE Corp.                         Phone: (650) 506-8830
 Java Products Group                  Fax: (650) 506-7303
 Languages & Obj-Relational Tech      Email: jofernan@us.oracle.com


Mime
View raw message