ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: svn commit: r537344 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/condition/
Date Mon, 14 May 2007 17:35:46 GMT

--- Kevin Jackson <> wrote:

> Hi Steve,
> > Not sure about this. Why take a string? Its not
> being resolved relative
> > to the project base, and is doing work that ant
> should do.
> >
> This is why I wanted someone to check over my
> resource stuff as I
> wasn't sure it was correct.
> > If we want to look in a resource for a string
> >   -the test should take any resource defined
> inline :
> >   add(Resource r)
> > or by a refid
> So if I change from setResource to add(Resource r)
> it would be more in
> keeping with the spirit of resources?
> Ok I'll look into making the changes and ensuring
> that the tests pass etc

Hi guys.  Sorry I've been having trouble keeping up
lately.  Saw this stuff but missed the intervening
discussion.  Started playing today with adding refid
support, etc., but after awhile it occurred to me that
we already had this covered, e.g.:

<resourcecount count="1">
    <file file="${file}" />
    <contains text="text" casesensitive="false"

Note that this approach supports any resource type
right off the bat.  Actually with the suggested "add"
idiom, <resourcecontains> should be rewritten as a
macrodef.  :|

If we decide to keep <resourcecontains> anyway, we
could plan something like this:

accept any nested resourcecollection but assert in
validation that it must have a single element (this
will include any Resource)

whenever we implement String resource decoding we can
add setResource(Resource) for IH to set for us.


> Thanks for the feedback
> Kev
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Sucker-punch spam with award-winning protection. 
Try the free Yahoo! Mail Beta.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message