Just to add more fuel to the fire - even if we were to change this behavior, it could not be for Ant 1.x since that would break backwards compatibility.
Now, this is a very good point and a valid reason why one wouldn't want to change the current behaviour.
Suppose, though, that Ant 1.x has behaviour that is "incorrect" (as defined by the majority of committers). How would people feel about correcting the behaviour UNLESS a "-legacy" flag was added to the command line, in which case the old behaviour would hold. This is similar to what was discussed with BuildExceptions on deprecated features, and would be used in the same way. If you had a build file that relied on the old behaviour, you would include the flag. Everyone else would get the "correct" behaviour by default.
Since relying on patternsets to behave this way is really an edge case (the only reason I can think someone would choose to do it is to get around limitations on extending referenced patternsets), it doesn't seem too onerous. I would be willing to create a patch for it. Of course all APIs would remain backward compatible.
There are other glaringly difficult issues with other datatypes that cannot be resolved in the 1.x codebase.
Would using a "-legacy" flag work for your examples? Or would the APIs have to change?
> Not only is this counterintuitive behaviour for the user, it takes away > functionality for no good reason.
Its only counterintuitive if you don't know how a fileset works with patternsets.
I don't want this to come off sounding harsh because I really appreciate your response and the time it has taken you to write it, but that statement is false. Not only that, it is dangerous thinking for a designer.
Intuition is not information. It is how things "appear" to work. The behaviour of multiple patternsets is counterintuitive. You may be able to overcome that intuitive response once you have enough information from digging around in the code, by using the feature all the time, or by memorizing the documentation, but that is not what most users will do. Users don't read documentation unless it is absolutely necessary. How often have you read the documentation on a door ("push" or "pull") only after failing to operate it intuitively. When that happens, the fault lies in the design of the door, not in you. And as this book http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0385267746&vm= proves time and again, "documenting counterintuitive behaviour = bad, fixing counterintuitive behaviour = good".
I agree that its currently not ideal, but the workaround Conor mentioned handles this particular situation relatively painlessly and intuitively, at least to me.
The example I gave was really to provide a test case for the bug/design decision, not to indicate where my problem lies. My real problem is in the APIs and the design of the classes. So no, Conor's workaround does not handle this painlessly, much less intuitively. I appreciate him having provided it, though. Thanks, Conor.
> Having separation in patternsets gives you this functionality. Then there > is the question of what a user would expect. If you were encountering an > ant build.xml file for the first time, would you expect old*.java to be > excluded? Honestly?
I know how a fileset works, so yes I would expect that behavior.
"If you were encountering an ant build.xml file for the first time"? Try to put yourself into the users' shoes.
I think your patch would still be a worthy feature to discuss adding even given the current way patternsets work.
That's probably a good idea. I can ignore how multiple patternsets interact for the time being.
I didn't get the patch finished this weekend, but I hope to get it ready by the next. Thanks for the encouragement.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
