Return-Path: <tad1@cornell.edu>
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 98299 invoked from network); 27 Jun 2000 15:59:42 -0000
Received: from postoffice2.mail.cornell.edu (132.236.56.10)
  by locus.apache.org with SMTP; 27 Jun 2000 15:59:42 -0000
Received: from pyro (pyro.cit.cornell.edu [128.253.57.45])
	by postoffice2.mail.cornell.edu (8.9.3/8.9.3) with SMTP id LAA06435
	for <ant-dev@jakarta.apache.org>; Tue, 27 Jun 2000 11:59:41 -0400 (EDT)
Message-Id: <3.0.2.32.20000627120014.012f42d0@postoffice2.mail.cornell.edu>
X-Sender: tad1@postoffice2.mail.cornell.edu
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) -- [Cornell Modified]
Date: Tue, 27 Jun 2000 12:00:14 -0400
To: ant-dev@jakarta.apache.org
From: Tom Dimock <tad1@cornell.edu>
Subject: Re: Possible Exec and MatchingTask Refactorings
In-Reply-To: <m3pup3tbkk.fsf@sbodewig.bost.de>
References: <Tom Dimock's message of "Tue, 27 Jun 2000 09:30:04 -0400">
 <3.0.2.32.20000627093004.00971100@postoffice2.mail.cornell.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N

At 04:58 PM 06/27/2000 +0200, you wrote:
>>>>>> "TD" == Tom Dimock <tad1@cornell.edu> writes:
>
> TD> Going in a slightly different direction with this, how about a
> TD> <worklist> task which creates a named list of files?
>
>My main problem with this is that it uses the Property mechanism (and
>even the ${} syntax - but I won't spoil .duncans chance to state his
>opinion on ${} 8^).

I didn't really make myself clear that I was NOT proposing that syntax,
rather I was just trying to get the idea of a worklist out there for
discussion.  Such a concept would help make many of my ant build files
simpler.  I have been on this list long enough to know that .duncan hates
the ${} syntax, but not long enough to know what was proposed to replace
it....

The main point was that a <worklist> could be used in different attributes
of a task like <exec> to get different behaviors. Having <exec> implement
the matchingtask behavior does lead to the ambiguities you mentioned. 

>I'm still not sure what to think of your idea.

Fair enough...   :-)  It was not too clearly stated!
----------------------------------------------------------------------------
       Tom Dimock  ----  Cornell University  ----  tad1@cornell.edu
"There go my people.  I must follow them, for I am their leader."  M. Gandhi