Return-Path: <donaldp@apache.org>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 62852 invoked from network); 16 Jan 2001 00:13:53 -0000
Received: from mail.alphalink.com.au (203.24.205.7)
  by h31.sny.collab.net with SMTP; 16 Jan 2001 00:13:53 -0000
Received: from donalgar (d18-ps3-mel.alphalink.com.au [202.161.108.146])
	by mail.alphalink.com.au (8.9.3/8.9.3) with SMTP id LAA05345
	for <ant-dev@jakarta.apache.org>; Tue, 16 Jan 2001 11:13:59 +1100
Message-Id: <3.0.6.32.20010116111218.0092deb0@alphalink.com.au>
X-Sender: gdonald@alphalink.com.au
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 16 Jan 2001 11:12:18 +1100
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: Re: The two views of Ant's future direction
In-Reply-To: <20010115191201.5666.qmail@web119.yahoomail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

At 11:12  15/1/01 -0800, Diane Holt wrote:
>In reading through all the mail regarding "Ant is/should-be a scripting
>language" vs. "No it's not and never was and never will be", I've been
>wondering if there's any room for compromise. I'm wondering if we could
>have the true-to-the-nonscripting-purists' vision of Ant as Basic Ant,
>then have the scripting-capabilities as extensions to that. Would it need
>another name? I don't know (but 'extant' comes to mind). Would it need to
>be a separate project? I don't know (clearly, 'extant' would be dependent
>on 'ant'). 

It's an option - maybe we could add an extra task-lib at Ant2.x time that
had these features. As long as I didn't have to support it then fine ;)

>Should Ant2 allow for the possibility of being extended to
>include the types of tasks such as <if>, <for>, <case>? I think so.

definetly. I have actually implemented it for my proposal but I didn't want
to submit it because it may invoke the wrath of the Ant gods ;)

>For simple projects,
>basic Ant would be all that would be needed -- but for large, complex
>build systems, Extended Ant could be used.

I suspect this is the exact reason why many people would oppose it. For
simple projects it is okay to use scripting as it does not increase
complexity however as projects become larger complexity increases. So using
scripts in a complex situation is just wrong IMHO because it makes them so
much more difficult to maintain and alter. I have been there and done that
(mainly with c/c++ projects thou ...) and NEVER want to go there again and
would encourage everyone to avoid it like the plague ;) My make files were
infested with that evil a4 language and seriously I thinking that
allowing/encouraging scripting in large projects is a great disservice to
our users.

I know as it stands there is issues in Ant1.x mainly as it evolved. However
with Ant2.0 we have a do-over so we can do things the *right* way. With
better Ant tasks/task structure I am under the impression that most of the
difficulties in Ant1.x can be eliminated (or at least I hope). For Jasons
case I can't see any problems using Ant2.0 and no scripting assuming
everything makes it in featurewise. For your case it is difficult because
of different JVMs and delicate ordering but I believe with unification of
property namespace to include filesets etc then it could be achieved.

One thing that would be great for your case is the ability to use embedded
evaluations. This is a common pattern in make but not used in ant. For
example consider the following

<property name="red.src" value="..." />
<property name="red.bin" value="..." />
<property name="red.dist" value="..." />
<property name="red.docs" value="..." />
<property name="red.lib" value="..." />

<property name="blue.src" value="..." />
<property name="blue.bin" value="..." />
<property name="blue.dist" value="..." />
<property name="blue.docs" value="..." />
<property name="blue.lib" value="..." />

<target name="...">

  <ant-call target="foo">
    <param name="color" value="red" />
  </ant-call>

  <ant-call target="foo">
    <param name="color" value="blue" />
  </ant-call>

</target>

<target name="...">

  <echo message="Task that compiles and builds ${${color}.src}" />
  ...

</target>

Would almost work for you. It would break some cases (namely when
inter-color groups are dependent) but these few cases could be "fixed" by
xslt/other.


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