ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Dimock <>
Subject Re: Possible Exec and MatchingTask Refactorings
Date Wed, 28 Jun 2000 14:24:10 GMT
At 12:43 PM 06/28/2000 +0200, "SB" Stefan  wrote:
>>>>>> "TD" == Tom Dimock <> writes:
> TD> At 04:58 PM 06/27/2000 +0200, you wrote:
> TD> but not long enough to know what was proposed to replace it....
SB>Well, one thing we all seemed to agree on was that properties should
SB>be richer objects, not just Strings, and that the Project would hold a
SB>java.util.Properties like repository of these.

Yes, yes, yes.  Or should I say +1   :-)

SB>I've not seen a proposal on how to set these properties with types
SB>other than String so far and in fact I've not seen an alternative to
SB>the ${} syntax. I think the last point should be done by passing the
SB>name of the property to the task and let the task evaluate it - just
SB>like the if/unless attributes of the include/exclude parts in
SB>MatchingTask work.

One problem with XML is that by making all attrubutes quoted, they
eliminated the most conventional way of distinguishing between a literal
and a reference.  The ${} syntax is pretty ugly, but is currently the way
ant is telling the difference between a literal value and a property
reference.  How would we do that if we wanted to eliminate ${} ?

SB>Your <worklist> would be a way to specify a property with file list
SB>value, right? So how about giving the Property task - it is a Task
SB>implementation after all - MatchingTask behavior?

Yes!  Exactly where I was headed.  The string-only aspect of properties had
prevented me from doing it the way you suggest, but if we make properties
richer objects, this becomes the way to do it.

SB><property name="files" dir="mybasedir>
SB>  <include ... />
       Tom Dimock  ----  Cornell University  ----
"There go my people.  I must follow them, for I am their leader."  M. Gandhi

View raw message