Return-Path: 
 <ant-dev-return-20159-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 34359 invoked from network); 25 Nov 2001 14:04:17 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 25 Nov 2001 14:04:17 -0000
Received: (qmail 20924 invoked by uid 97); 25 Nov 2001 14:04:15 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 20908 invoked by uid 97); 25 Nov 2001 14:04:15 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 20897 invoked from network); 25 Nov 2001 14:04:14 -0000
Message-ID: <00d801c175ba$0d82b040$6401a8c0@darden.virginia.edu>
From: "Erik Hatcher" <jakarta-ant@ehatchersolutions.com>
To: "ant-dev" <ant-dev@jakarta.apache.org>
Subject: <available> / <condition> breaking immutability
Date: Sun, 25 Nov 2001 09:04:08 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

I've been struggling with this issue for a bit and its time to get more
views on it...

I can see both sides to this, but why does <available> and <condition> (and
<uptodate>, <tstamp>, and some others) break non-user property immutability?
Is this inadvertent or intentional?

It seems reasonable for <available> to get the final say on setting a
property as it would be strange to have a situation like this:

    <property name="jar.exists" value="false"/>
    <available property="jar.exists" file="some.jar"
filepath="/path/with/the/jar" type="file"/>

And jar.exists will be set to "true" in the above case.  But what about
this:

    <property name="jar.exists" value="true"/>
    <available property="jar.exists" file="some.jar"
filepath="/path/without/the/jar" type="file"/>

Shouldn't we also unset the property if we are going to override it and
break immutability in the "true" case?  Or should user property immutability
be strengthened?

I'm (mostly?) of the opinion that <available> and such tasks that set a
property based on some condition should force the setting/unsetting of the
specified non-user property.  If there is really a need to force a specific
value for one of these, then the -D option (and via <ant>/<antcall>) has the
final say anyway, so there is a way to force past the overriding if it is
truly desired.

Thanks,
    Erik



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>