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 on.
Would anybody mind if I code this into available, instead of creating a new task availablelist? ----- Original Message ----- From: "Stefan Bodewig" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 23, 2000 11:01 AM Subject: Re: Call for patches > >>>>> "BB" == Bill Barnhill <[EMAIL PROTECTED]> 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, you > explicitely say this is not the opposite of availablelist so the name > is kind of misleading. What I gather from your description: > > * All resources are there => avalailablelist is true, notavailablelist > 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 needs > a bunch of good documentation to match the simplicity goal). > > Stefan >
