Return-Path: <jakarta-ant@ehatchersolutions.com>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 67551 invoked from network); 7 Feb 2003 08:43:45 -0000
Received: from h001.c000.snv.cp.net (HELO c000.snv.cp.net) (209.228.32.65)
  by daedalus.apache.org with SMTP; 7 Feb 2003 08:43:45 -0000
Received: (cpmta 10368 invoked from network); 7 Feb 2003 00:43:57 -0800
Received: from 68.169.37.64 (HELO ehatchersolutions.com)
  by smtp.hatcher.net (209.228.32.65) with SMTP; 7 Feb 2003 00:43:57 -0800
X-Sent: 7 Feb 2003 08:43:57 GMT
Date: Fri, 7 Feb 2003 03:44:09 -0500
Subject: Re: unset a property of a project.
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
From: Erik Hatcher <jakarta-ant@ehatchersolutions.com>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Content-Transfer-Encoding: 7bit
In-Reply-To: <3E435F6A.4070101@germane-software.com>
Message-Id: <53364712-3A78-11D7-B92A-000393A564E6@ehatchersolutions.com>
X-Mailer: Apple Mail (2.551)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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 
"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="firstgroup@somewhere.com"/>, <antcall target="sendMessage"/> 
> followed by <property name="mail.to" 
> value="secondgroup@somewhere.com"/>, <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