ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: [SUBMIT] file set cullers
Date Tue, 03 Apr 2001 14:36:19 GMT
David Rees <d.rees.l@usa.net> 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.

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'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
weird?

> 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
direction.

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?

> * 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?

> Makes a clone of the fromDir in the toDir. It first deletes those
> files that do no exist in the fromDir. Then copies only those files
> that don't exist or have changed.
> 
> <mkdir dir="${to.dir}" />
> <delete>
>   <fileset dir="${to.dir}">
>     <filecompareculler compareDir="${from.dir}" exists="no" />
>   </fileset>
> </delete>
> <copy toDir="${to.dir}">
>   <fileset dir="${from.dir}">
>     <cullerset logic="or">
>       <filecompareculler compareDir="${to.dir}" exists="no" />
>       <filecompareculler
>         compareDir="${to.dir}"
>         dateNotEqual="cullee" />
>     </cullerset>
>   </fileset>
> </copy>

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.

> 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.

Stefan

Mime
View raw message