ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject <available> / <condition> breaking immutability
Date Sun, 25 Nov 2001 14:04:08 GMT
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>


Mime
View raw message