ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: unset a property of a project.
Date Fri, 07 Feb 2003 08:44:09 GMT
On Friday, February 7, 2003, at 02:25  AM, Dale Anson wrote:
> 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 

> 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="" 
> value=""/>, <antcall target="sendMessage"/> 
> followed by <property name="" 
> value=""/>, <antcall target"sendMessage"/>. 
> Instead I have to do something like <property 
> name="" 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 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.


View raw message