ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Rees <>
Subject Re: [SUBMIT] file set cullers
Date Tue, 10 Apr 2001 03:58:21 GMT
Up front, I would like to say I could go either way on Ant1.4 having
it. I think there really is need, but I am looking forward to having
it done "right" for Ant2 with true generic sources.

On 03 Apr 2001 16:36:19 +0200, Stefan Bodewig wrote:

>David Rees <> wrote:
>> Attached is my second cut at the culler functionality I mentioned
>> last week.
>antCull.diff is empty, so I've only seen your new source code - I
>guess the major part of it happens in FileSet and DirectoryScanner.

I strongly apologize for that. Not sure what happened. I have resent
the updated diff file.

Generally the major part doesn't happen in FileSet or
DirectoryScanner. FileSet had the slight modification to contain

DirectoryScanner has minor modifications (in terms of code change) to
also check cullers in addition to its patterns.

>The only thing I want to say about the actual implementation: I'm not
>too sure about the getSourceFile method in CullerSource as files
>really are a (very common) special case. Maybe this should be even
>more abstracted out so that CullerSource provides access to things
>like last modification time (which you could get for FTP entries or
>ZipEntry as well). Just a random thought.

I agree.

My thought here for the Ant1 submission was to place a common hook for
catching a File based culler being used with a non-File source. You
are right that because it returns a File the API only really works for
directory Files. The problem is that Java doesn't have an interface
for File, so new "Files" need to use a different type (like FTPFile).

For Ant2 I would like to expand on source, possibly adding a fascade
for File that supports the various types of Files (FTP, Zip, URL). Its
a bit of work, but it needs be done. Maybe there a small framework out
there we can borrow that does some of this already?

>I'm not sure about the name "culler". I went to SysTran and e-lingo
>and tried to translate it to German, neither knew the term - so I
>tried "cull" and retrieved two very different translations. SysTran
>said "Ausschu├č" which means either something like board/committee or
>garbage, neither makes sense to me. e-lingo said "Auswahl" which is
>choice in English. Is the term ambiguous or is SysTran's database

As someone mentions a little later on, the first definition of cull is
to "choose from group". However, I can certainly understand that given
recent events in Europe its secondary meaning has become more
prevalient. I'm not tied to it, a search and replace to something else
would be easy if there are any suggestions?

>> As before, my thoughts for how this "should" be done in Ant2 will be
>> in different post (later).
>How different is this Ant2 vision from what you propose now? If even
>you think the functionality or API or XML representation has to be
>radically different ...
>Yes, I think your cullers satisfy a strong user need, and yes, I'm a
>little hesitant to add something this big now, when we'd be sure that
>we would drop it for a radically different mechanism in Ant2.
>Judging from the discussion so far, we seem to agree that we want to
>support include/exclude based on different criteria - maybe without a
>fixed set so that something pluggable like Culler might be the right
>Getting my act together ;-): I'd prefer if we could first figure out
>how we want to support the mechanism you tackle with your proposal in
>Ant2 - then you adapt your proposal to get as close to the way Ant2 is
>supposed to work as possible and we commit it in the 1.x branch.
>Would that work for you?

Hmmm, not a bad approach really. In my mind I think I have reconciled
what I am thinking for Ant2 with what I did, so I guess I have to
prove it my documenting it. Do we have a planned approach for how we
will design "parts" of Ant2? Otherwise I will just put a basic design
document together for Ant2.

>> * Length Attributes
>> For length attributes, any long that can be read by Java Long or
>> "ignore" is supported. The length is in bytes.
>> lengthEqual
>>   Selects file if its length equals the indicated length.
>> lengthNotEqual
>>   Selects file if its length does not equal the indicated length.
>> lengthLessThan
>>   Selects file if its length is less than the indicated length.
>> lengthGreaterThan
>>   Selects file if its length is greater than the indicated length.
>Do we really need four attributes for this, especially if you'd move
>the not-attribute from CullerSet to Culler, putting the inversion
>logic right here?

I think we need at least three or some other way of defining it. I
played with possibly using "<=" kinds of notation, but I thought this
was cleaner. The lengthNotEqual is really useful for its subclass.
Though we could easily move not to the culler level.

>While I like the first one, the second could be achieved without any
>cullers at all - I know its just an example.
>> For developers that use the DirectoryScanner class directly, cullers
>> do not effect the filesExcluded and dirsExcluded values. A file is
>> either included or notIncluded.
>I think we all need to think about DirectoryScanner three value logic
>of included/excluded/notIncluded a little more - and decide whether it
>is actually necessary.

Yeah, I really think it isn't. That certainly will not be in a Ant2
proposal of my mine...

>> In addition, an add<YourCullerName> method must be added to FileSet
>> and CullerSet to allow the culler to be included.
>Ouch, there should be an easier way - I know this is close to
>impossible in the current environment.

I agree. I looked to modify Ant1 to support subtyping, but the way
that IntrospectionHelper interacts with Tasks makes it sort of
impossible without breaking something else. I really feel that Ant2


View raw message