ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Oxspring" <roxspr...@yahoo.com>
Subject RE: cullers
Date Tue, 26 Feb 2002 01:48:41 GMT
> -----Original Message-----
> From: Magesh Umasankar [mailto:umagesh@apache.org]
> Sent: Tuesday, February 26, 2002 12:55 AM
> To: Ant Developers List
> Subject: Re: cullers
>
>
> From: "Bruce Atherton" <bruce@callenish.com>
>
> >
> > >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:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message