From: "Bruce Atherton" <[EMAIL PROTECTED]>
>
> >Anyway, the basic difference _conceptually_
> >is 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.
>
> Huh? Did I completely misunderstand your code?
>
> My understanding is that selectors cannot add entries to a pattern,
despite
> their name. They can only choose to veto the entries supplied by an
> <include>. So if you have two files like:
>
> File.java - 10K
> File.class - 8K
>
> then this:
>
> <fileset>
> <include name="*.java">
> <selector type="size"
> operation="greater-than"
> value="4K"/>
> </include>
> </fileset>
>
> selects only File.java, despite the fact that File.class passes the
> selector condition. Looks to me like it is selecting a subset of the files
> indicated by <include>, as well. If I am confused about this, then this is
> another argument against selectors since I doubt I'd be the only one
> confused (although perhaps I just confuse easily).
>
<include name="*.java"> is the shorthand notation
for specifying
<include name="*">
<selector type="name" operation="equals" value="*.java"/>
</include>
Attribute name is in there for backwards compat reasons...
Your problem can be addressed easily as follows:
<fileset>
<include name="*">
<selector type="name"
operation="equals"
value="File.*"/>
<selector type="size"
operation="greater-than"
value="4K"/>
</include>
</fileset>
> >Let us say, I want to include all files
> >that have a size > 4 K but exclude those
> >that are readonly with names beginning
> >with "Test" with extension "jar" whose size
> >is greater than 5K
> >
> > <fileset>
> > <include name="**/*">
> > <selector type="size"
> > operation="greater-than"
> > value="4K"/>
> > </include>
> > <exclude name="**/Test*.jar">
> > <selector type="permission"
> > value="r"/>
> > <selector type="size"
> > operation="greater-than"
> > value="5K"/>
> > </exclude>
> > </fileset>
> >
> >How would you do that in your proposal?
>
> (I pasted in your corrected version above).
>
> You want a way to specify that all cullers should agree before a file is
> culled. Not a problem:
>
> <fileset>
> <include name="**/*">
> <sizecull size="4" units="k" when="less"/>
> <agreecull>
> <sizecull size="5" units="k" when="more">
> <permcull attrib="readonly"/>
> <filenamecull name="**/Test*.jar/>
> </agreecull>
> </fileset>
Looks good. Though I would like it better if
you name it <and> instead of <agreecull>. Also,
I think it would be easier for people to
grasp the name selector instead of cull, as selector,
I think, is a more common word ;-) I would
also be interested in seeing a <selectorset>
that can be passed as reference to <fileset>.
>
> But your example is carefully selected, which demonstrates my point. It
> relies on the selection being related to the file name. If you remove that
> requirement, the problem becomes: I want to include all files that have a
> size > 4 K but exclude those that are readonly whose size is greater than
> 5K. The answer flows nicely out of the problem:
>
> <fileset>
> <include name="**/*">
> <sizecull size="4" units="k" when="less"/>
> <agreecull>
> <sizecull size="5" units="k" when="more">
> <permcull attrib="readonly"/>
> </agreecull>
> </fileset>
>
> The solution using selectors, though, is a little bizarre because it
> involves an <exclude> that starts off excluding everything, and then
relies
> on its selectors to trim it to size. Is this trip really necessary?
>
> <fileset>
> <include name="**/*">
> <selector type="size"
> operation="greater-than"
> value="4K"/>
> </include>
> <exclude name="**/*">
> <selector type="permission"
> value="r"/>
> <selector type="size"
> operation="greater-than"
> value="5K"/>
> </exclude>
> </fileset>
>
<exclude> works on the previously <include>d items
only. There is no extra trip.
>
> >I am not saying I am happy with the generic
> >way in which I have implemented it - I recognize
> >though that there is no _clean_ solution
> >in Ant1, where we can have Ant's selectors and
> >user-defined pluggable selectors match up in
> >syntax.
>
> Ahh, but why is that necessary? What benefit is there in forcing every
> selector/culler into the same straightjacket?
Consistency and less support calls like "why am
I not able to specify a selector like Ant Core
does?"
>
> If it will help, I can clean up <extendcull> and post it. Let me know.
>
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.
I am not convinced that there is a serious problem with
the selector proposal - I am biased, of course ;-)
But I would welcome your submission with the extension
mechanism et al, as I won't have the time to implement
completely the selector proposal in the next few weeks...
Cheers,
Magesh
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
