ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barnhill" <>
Subject Re: Call for patches
Date Wed, 24 May 2000 03:06:26 GMT
Thank you for stating that better than I did. :)
I originally thought of extending the available task to simply accept
files, classes, and resources attributes as well as file, class,
resource attributes, but decided that would probably be frowned upon
as it touched somebody else's code.  As I said, this is my first open
source project so I ahve no clue as to the etiquette of what is
touchable and what isn't.  It does seem to make more sense and then
notavailablelist would become notavailable, which is more readable.
You hit my intended behavior for availablelist and notavailable dead

Would anybody mind if I code this into available, instead of creating
a new task availablelist?

----- Original Message -----
From: "Stefan Bodewig" <>
To: <>
Sent: Tuesday, May 23, 2000 11:01 AM
Subject: Re: Call for patches

> >>>>> "BB" == Bill Barnhill <> writes:
>  BB> Instead of multiple if's, it is a task called availablelist
>  BB> which takes paramters classes, resources, and files, each of
>  BB> which are plural versions of the class, resource, and file
>  BB> parameters of the available task.
> I'd prefer a solution like this as it wouldn't require a change to
> Ant's core but merely add a task.
> But wouldn't it be better to extend the functionality of available
> instead of adding a new task with overlapping concerns?
> As for the notavailablelist task you describe in a different mail,
> explicitely say this is not the opposite of availablelist so the
> is kind of misleading. What I gather from your description:
> * All resources are there => avalailablelist is true,
> is false.
> * None of the resources are there => avalailablelist is false,
> notavailablelist is true.
> * Any one of the resources is there but not all of them => both
> availablelist and notavailablelist are false.
> This makes for powerfull combinations but looks tricky (read as
> a bunch of good documentation to match the simplicity goal).
> Stefan

View raw message