From ant-dev-return-26437-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org Mon Feb 25 23:58:08 2002 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 45986 invoked from network); 25 Feb 2002 23:58:07 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 25 Feb 2002 23:58:07 -0000 Received: (qmail 28898 invoked by uid 97); 25 Feb 2002 23:58:09 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 28882 invoked by uid 97); 25 Feb 2002 23:58:09 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 28871 invoked from network); 25 Feb 2002 23:58:09 -0000 Message-Id: <5.1.0.14.0.20020225145242.03cf1508@orson.callenish.com> Date: Mon, 25 Feb 2002 15:58:06 -0800 To: "Ant Developers List" From: Bruce Atherton Subject: Re: cullers In-Reply-To: <007601c1be45$f38cb3f0$270610ac@manu.com> References: <5.1.0.14.0.20020224224232.03a6ad60@mail.callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N At 04:46 PM 2/25/2002 -0500, Magesh Umasankar wrote: >On the same note, isn't too another >name for ? You cull those files >which match a specified file name pattern. No, I would say that is the thing that can _add_ entries to a pattern and is the thing that can take entries back out but only once they are put in by an . Now, with cullers and selectors, there are other things that can take entries out of a pattern. Thus, is a form of culler/selector whereas is its own beast. >Anyway, the basic difference _conceptually_ >is you ask the user to select a set of files >using 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 . So if you have two files like: File.java - 10K File.class - 8K then this: 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 , 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 > > > > operation="greater-than" > value="4K"/> > > > value="r"/> > operation="greater-than" > value="5K"/> > > > >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: The solution using selectors, though, is a little bizarre because it involves an that starts off excluding everything, and then relies on its selectors to trim it to size. Is this trip really necessary? >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, and are two different tags, with different attributes. User-defined cullers have to "match up" with the 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 and post it. Let me know. -- To unsubscribe, e-mail: For additional commands, e-mail: