Return-Path: <pjdonald@cs.latrobe.edu.au>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 31801 invoked from network); 13 Oct 2000 05:56:13 -0000
Received: from mail.alphalink.com.au (203.24.205.7)
  by locus.apache.org with SMTP; 13 Oct 2000 05:56:13 -0000
Received: from donalgar (d04-ps0-mel.alphalink.com.au [202.161.104.4])
	by mail.alphalink.com.au (8.9.3/8.9.3) with SMTP id QAA16109
	for <ant-dev@jakarta.apache.org>; Fri, 13 Oct 2000 16:56:11 +1000
Message-Id: <3.0.6.32.20001013165848.0089be20@latcs4.cs.latrobe.edu.au>
X-Sender: pjdonald@latcs4.cs.latrobe.edu.au
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 13 Oct 2000 16:58:48 +1000
To: ant-dev@jakarta.apache.org
From: Peter Donald <pjdonald@cs.latrobe.edu.au>
Subject: RE: [PATCH] New <case> task
In-Reply-To: <20001012123001.20623.qmail@web117.yahoomail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

>Personally, I find the limitation imposed on the if/unless to only that of
>set/not-set rather than also being able to test for value, just to try and
>keep Ant from having a "scripting" capability, rather odd. Testing whether
>something is set or not-set is still "scripting" -- you're still
>determining what will and won't be done, based on some criteria. Yes,
>there are all kinds of ways to work around this limitation, but they all
>get cumbersome and, I find, make the whole process far more complicated
>than it really needs to be. I would love to be able to do something like:
>  <property name="out.dir" value="${debug.dir}" if="sane=true"/>
>  <property name="out.dir" value="${release.dir}" if="sane=false"/>

No offense but thats because you are still thinking that ant is make and
treating it the same way. Given the above example would the following work

  <property name="out.dir" value="${release.dir}" if="sane!=false"/>
  <property name="out.dir" value="${release.dir}" if="sane=FALSE|sane=false"/>
  <property name="out.dir" value="${release.dir}" if="sane=^false"/>

all these things are "easy" to read and just as clean as above solution -
would you accept them  ? A few generations more and we would end up a full
regex evaluation - and then guess what it is not easy to read. 

>It's clean, 
I don't think so

>it's concise,

nope again ;)

> it's human-readable. 

and so is make ...

>As things stand now,
>though, I need to do all of that sort of thing over in the ant
>wrapper-script. My ant wrapper-script is already far larger and more
...snip...

Ant is not a drop in replacement to make and it is not meant to be used in
the same way. If you want make - there is already one of them available ;).
Have a look at the way other apache projects use build.xml to see how they
are different (Avalon, JAMES and Cocoon all have decent build.xml files -
with Avalon being most complex and best). 

If you really want to alter ant instead propose a frontend interface and
get it doing stuff in a preprocessor stage. I just see it as extremely
unlikely that any such "enhancements" will ever make core - at least while
the original predecessors of Ant are around (and I assume they lurk or
monitor). You should have seen the "discussions" when someone decided to
add if functionality. That debate lasted weeks and was only grudgingly
allowed - thus why I see it as virtually impossible that such behaviour as
you want will ever get to core. 


Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*