> -----Original Message-----
> From: Magesh Umasankar [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 26, 2002 12:55 AM
> To: Ant Developers List
> Subject: Re: cullers
>
>
> 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.
Nitpicking:
The idea of a set of selectors surely cannot be right. Would it not make
sense to define an instance of a "selector" and then use refid to bring in
the *single* selector required - this way you force people to explicitly
choose "and" / "or" selectors when attempting to combine them.
Bluesky:
Both of the proposals seem to be addressing the short sightedness of the
include/exclude mechanism which is great. Ideally I would like to see
include and exclude dumped in favour of something more generic:
<fileset dir="...">
<and>
<filesize size="4" units="k" when="more"/>
<not><and>
<filename pattern="Test*.jar"/>
<perimission attrib="readonly"/>
<filesize size="5" units="k" when="more">
</and></not>
</and>
</fileset>
I'm sure the include/exclude mechanism can be comforably mapped onto this
structure but am struggling to think how it can sensibly live along side it.
My 2p:
In terms of preferences I'd definitely mix and match: the name selector goes
down better but I think the custom ui for the tags is infinitely better than
the operation= value= approach. - Even if we have to go down the hard coded
implementations for now a la condition. The extendcull sounds like an
interesting idea. () Perhaps a "base" selector could implement some
introspection to decide which generic params to use - so that people can
code up selectors to work with a nice ui but in the meantime (before they
get it added to ant core) they ca access the attributes though nested param
elements. So that the generic version would look:
<selector classname="MyCVSSelector">
<param name="status" value="Locally Modified"/>
</selector>
but then when added to ant properly (via a patch to BaseSelector or Ant2
style polymorphism etc) it could be accessed as:
<cvsselector status="Locally Modified"/>
Maybe this is all included in the extendcull proposal - if so forgive me as
its late and time i slept.
Rob
>
> 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]>
>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
