I am especially interested to understand what prompted you to invest the time to create a totally new proposal - did you notice glaring _fundamental_ defeciency in the selectors proposal?
A fair question. The answer is that I had already done most of the work.
Back in December, I mentioned that I was going to work on this: http://marc.theaimsgroup.com/?l=ant-dev&m=100715331627473&w=2. I got most of the way through it when you committed your proposal for selectors. I abandoned what I was doing since there didn't appear to be a need for it anymore.
Then a couple of weeks ago, I started going through how Selectors worked and saw that we had somewhat different visions for how things should work:
1) Selectors require changes to Ant1 that change the API a lot more than necessary. I had already worked out how to add the functionality without altering any interfaces or adding new types, so I didn't see the need for Selectors to do it. Perhaps this isn't a big issue but why change things if you don't have to?
2) Selectors were elements of <include> and <exclude>. This struck me as needlessly complicated. If it weren't for the historical issues, I would argue very strongly that <exclude> is just another name for <filenamecull>, and should be treated no differently. Given that <exclude> is a type of culler, other cullers belong at the same level.
More than that, differentiating the behaviour of two sets of selectors introduces complexity that is hard to understand. When it is in an include block, it acts to select certain files (and cull the rest), but when it is in an exclude block it is a culler of a culler. Even if you buy that this is a desirable behaviour, and I don't because I think it makes things hard to grasp, why the artificial limit on only allowing multiple levels in one particular type of selector, the <exclude>? Why not select from the files selected by any of the other selectors, ad infinitum? Scary thought, no? That's why I'm not fond of selectors in exclude.
3) Selectors are required to use a generic interface for the attributes. I think that this should only be done when you absolutely have to. The more information you can give to a user to do the right thing, the better off you and they are. It makes no sense that the cullers/selectors bundled with Ant should be restricted in this way, it just makes things needlessly awkward. Why not have a single generic <task> in that case?
What I designed requires support for specific cullers within PatternSet and FileSet, but that seems to be sensible for the bundled cullers. Because Stefan requested the behaviour, I also worked on a way to add new cullers dynamically. I figured that the Decorator pattern was the most effective way to get this behaviour until I could work out whether it was possible to do things dynamically the Ant way with reflection (which may not be possible in Ant1), hence <extendcull>. The <extendcull> works exactly the way Selectors do, by having a fixed set of attributes. It goes farther, though, in that it also allows dynamic definition of new cullers within the build.xml file itself. It also allows dynamically loading the properties file that defines the definition between type and class name. I'm not sure, but it didn't look to me like Selectors would do these things. It seemed like a user would have to edit the properties file inside the ant.jar to add new selectors. I may have misunderstood.
Anyway, back to your question. None of these issues were fundamental enough for me to write a new proposal from scratch. But then, I didn't have to. I already had a version that had most of this stuff, I just had to complete it. So rather than make the modifications to the existing selector code which would have been more work for me, I dug out my old mods.
I think this proposal is a cleaner way to go for the reasons I give above. If people don't agree, no harm done. The extra effort I put in can just be chalked up to concrete examples of how to solve the issues I've raised. And if people do agree, all the better since this portion is done.
There is still more work to be done (fixing up and submitting <extendcull>, for example), but I won't bother unless there is a need or people decide to adopt the proposal.
I hope that answers your question.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
