At 04:46 PM 2/25/2002 -0500, Magesh Umasankar wrote:
>On the same note, isn't <include> too another
>name for <filenamecull>? You cull those files
>which match a specified file name pattern.
No, I would say that <include> is the thing that can _add_ entries to a
pattern and <exclude> is the thing that can take entries back out but only
once they are put in by an <include>. Now, with cullers and selectors,
there are other things that can take entries out of a pattern. Thus,
<exclude> is a form of culler/selector whereas <include> is its own beast.
>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).
>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>
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>
>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?
With the cullers proposal, <sizecull> and <extendcull> are two different
tags, with different attributes. User-defined cullers have to "match up"
with the <extendcull> syntax, but there is still freedom for the standard
cullers to do the right thing. I don't see a benefit to limiting all of
them to a single interface, just because they belong to the same general
category.
>Yes, that had been pointed out earlier.
>I was planning to rework it such that it
>could be defined from build.xml as well,
>just as you say youhave done it.
If it will help, I can clean up <extendcull> and post it. Let me know.
--
To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
|