I can think of several cases for unsetting or resetting a property:
1. <timestamp/> cannot be called repeatedly with the same property.
You mean <tstamp>, I presume. This is why there is a 'prefix' attribute on that task, allowing you to set timestamps within different "namespaces".
2. Ditto for <input/>
I've not had a need to use <input> but why not just have different property names for each input item?
3. Depending on which set of unit tests fail, I want to send e-mail to a particular individual or group. I cannot do <property name="mail.to" value="[EMAIL PROTECTED]"/>, <antcall target="sendMessage"/> followed by <property name="mail.to" value="[EMAIL PROTECTED]"/>, <antcall target"sendMessage"/>. Instead I have to do something like <property name="mail.to.firstgroup" value="..."/> etc. Same logic applies to subject, message body, and mail server.
This could be handled by some clever use of the ant-contrib <propertycopy> task. (In fact, I'd like to see this task migrated to Ant's codebase)
I've written a number of tasks that address these "problems". I realize they are not necessarily the "Ant way" of doing things, but are a natural way for many developers. In particular, I've written a <var> task that is a mutable property. This is a flat out misuse of Ant properties, but is very handy. Basically, it uses the publicly accessible user properties hashtable in org.apache.ant.Project to read and write properties. As the user property hashtable takes precedence over the other properties hashtable, it is also possible to override a regular property. So constructs like this are possible:
Hmmmm..... I thought we changed the API to return a copy of the Hashtable rather than the one used by Project. I haven't gone to the code to re-verify though.
<property name="doit" value="false"/> <target name="dosomething" if="doit"> ... </target>
It is counter-intuitive to think that the "dosomething" target would execute since "doit" is false. This is much more intuitive:
<property name="doit" value="false"/>
<target name="dosomething">
<if name="doit" value="true">
<!-- now do it -->
</if>
</target>
No argument about the if/unless constructs in Ant. They are a bit confusing, no question.
Anyway, I've rambled and ranted enough. The tasks I mentioned are available at antelope.sourceforge.net. Just this morning I finished <antcallback>, which is identical to <antcall> except it supports a "return" parameter, so you can do something like this:
<target...>
<antcallback target="setAValue" return="a"/>
<echo>${a}</echo> <!-- will print out got it -->
</target>
<target name="setAValue"> <property name="a" value="got it"/> </target>
Very interesting.
I'll probably post this task on sourceforge tomorrow. There is already an <antfetch> which does almost the same thing for <ant>.
You're definitely pushing the limits of Ant's intent and design, but it looks like you've found enough extensibility options to satisfy your needs, and that is a good thing, even if Ant itself will not incorporate these features.
I personally use ant-contrib's <propertycopy> task in all my builds now.
Erik
