<include name="*.java"> is the shorthand notation
for specifying
<include name="*">
<selector type="name" operation="equals" value="*.java"/>
</include>
Although they end up in the same place, they take different routes to get there.
Think about it in terms of set theory, where PatternSets define rules for a set and FileSets define a particular instance of the set.
Your first example says: fill the set with elements that match the filename *.java.
Your second example says: fill the set with everything, and then take the intersection of that set and the set of elements which match the filename *.java.
Attribute name is in there for backwards compat reasons... Your problem can be addressed easily as follows:
I don't have a problem. I was just pointing out that your claim that "you ask the user to select a set of files using <include> and then select a subset of them. Whereas, my proposal lets the user to select just the set of files that is needed" is wrong. They both work the same way, selectors are just muddier about what they are doing.
Looks good. Though I would like it better if you name it <and> instead of <agreecull>.
<grin> I carefully avoided <and> since there is such sensitivity on this list to anything that smacks of the slippery slope of scripting, previously added features notwithstanding.
Also, I think it would be easier for people to grasp the name selector instead of cull, as selector,
Whatever. I wrote that code in December, when I was told that the concept was called cullers, so that's what I called it.
If we're going to paint this bikeshed, though... Since conceptually it is limiting what can go into a PatternSet or FileSet, don't you think a word that suggests removal is better? "Exclusions" is too long, but that sort of idea. "Cull" works well here since it is nice and short, but I hear what you are saying about the term being rare.
I would also be interested in seeing a <selectorset> that can be passed as reference to <fileset>.
Not sure I grasp the point here. PatternSet already does this. Why do you need another? The only reason I can think of is to get around the PatternSet "mingling" I was discussing last week, and if that is the issue there may be better ways to tackle it.
<exclude> works on the previously <include>d items only. There is no extra trip.
Sure there is, in the same way as your first example: by (conceptually, if not in code) creating a set of everything and then taking the intersection of that set and the set of read only files and the set of files with size greater than 5. Why is the set of everything in there? Only because you've forced it on the user whether they want it or not.
Consistency and less support calls like "why am I not able to specify a selector like Ant Core does?"
We're talking about different things, static and dynamic selectors. You seem to assume that users won't be able to differentiate between the two, but I don't believe that. And there is a very large usability downside to forcing consistency on these similar but different things. If consistency isn't making something MORE usable, why do you want it?
Of course we all want users to be free to do everything in their own classes that they can do in Ant, but in many, many ways that is going to have to wait until Ant2. No need to make life for users any more unpleasant than necessary until Ant2 arrives, though.
Please do so and also consider the following requests: * naming culler as selector, * culler must select items from a list - not select away, If you want it the other way, name it <deselect> * selectorset with nested selectors, and, or, not elements, and referencable by id so that it can be reused in other filesets.
As far as the name goes, either way it is limiting the list rather than adding to it. <limit>? <limit-to>? I don't know. I'm not sure <deselect> is quite the right idea. Does anyone have any suggestions? I mean Magesh, if after reading my comments on this you are still convinced that <selector> is correct, I can do that, it's no big deal. It just doesn't seem to describe the action being requested to me, but rather what Erik was thinking it meant.
I can change the sense of the boolean return value, no problem. I don't care which way it goes, so long as it is clear from the name which direction it goes in.
I still don't understand the need for selectorsets, but I'm willing to be convinced.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
