Re: Find (was: New tasks.)

[Mariusz Nowostawski <ma...@marni.otago.ac.nz>]

>> Proposal for a new task: find
>> It would look like this:
>> 
>> <find basedir=... includes=... excludes...>
>>    <task1 ... ${find.file} ${find.dir} ... />
>>    <task2 ... ${find.file} ${find.dir} ... />
>>    ...
>> </find>
>> 
>> Analogous to Unix   find <dir> -name <regexp> -exec <task>
[...]

> Good idea, I would just suggest that if the result of <find> is
> in find.file and find.dir properties, why nest <task1> and <task2>
> in <find> ? I would rather imagine something like :

> <find basedir=... includes=... excludes.../>
> <task1 ... ${find.file} ${find.dir} ... />
> <task2 ... ${find.file} ${find.dir} ... />
[...]

>> Any value?  I haven't coded one up yet.


I do not like personally 'find' model to be present in ANT. I like a
lot, the way processing of my build inputs works currently in ANT - which
is distinct from traditional 'make' and 'find'-based models. 

I cannot see when:
<task1 ... ${find.file} ${find.dir} ... /> 
<task2 ... ${find.file} ${find.dir} ... />
would be of use?  Everywhere the task can take a list of files, it itself
implements include/exclude model, like javac/delete etc.  With find we 
would have two ways of doing the same thing, which I feel would break
the rule of making things simple.  For example if I have to compile
all my java source files in one directory and then copy them to the
distribution src directory, in current ANT, with 'no-find-philosophy'
I do: 

1. compile all java files from _src.dir_
2. copy all java files from _src.dir_ to _dist.dir_

with 'find' it usually looks like:

1. find all the java files from _src.dir_
2. compile all what's in ${find.file} ${find.dir}
3. copy all what's in ${find.file} ${find.dir} to _dist.dir_

Do not tell me that you do not like the beauty, simplicity and
the very explicit way of the first (current ANT) model. Everywhere ANT 
lacks the excludes/includes model (like in current exec) it needs
simple to be extended. Apart from that, in Unix:  
   find <dir> -name <regexp> -exec <task>
<task> is performed sequentially one call per found item. In most cases 
(like in the one with compiling and copying) you do not want the task
to be performed n times, once per each found item, you want it to be
performed once with the list of items (which I suppose the propose
find task would differ from the real 
      find <dir> -name <regexp> -exec <task> ).

Do not get me wrong, I love 'find', and it would be not possible to
have 'make' without it, but I am very happy not to have find in ANT, 
and I do not feel the need for it here either. When do you need find
task to be used? and with what tasks?

-1

regards
Mariusz

Re: Find (was: New tasks.)

[External Lists <ex...@ManagedObjects.com>]

Okay, Mariusz.  I see your point.  You're saying ANT only needs one "visitor
pattern" implementation, and includes/excludes is already present.  For
those tasks that don't implement it, they should be extended.  I can live
with that, too.  It's also simpler than nesting tasks.

-1

John


----- Original Message -----
From: Mariusz Nowostawski <ma...@marni.otago.ac.nz>
To: <an...@jakarta.apache.org>
Sent: Sunday, May 07, 2000 6:34 PM
Subject: Re: Find (was: New tasks.)


>
> >> Proposal for a new task: find
> >> It would look like this:
> >>
> >> <find basedir=... includes=... excludes...>
> >>    <task1 ... ${find.file} ${find.dir} ... />
> >>    <task2 ... ${find.file} ${find.dir} ... />
> >>    ...
> >> </find>
> >>
> >> Analogous to Unix   find <dir> -name <regexp> -exec <task>
> [...]
>
> > Good idea, I would just suggest that if the result of <find> is
> > in find.file and find.dir properties, why nest <task1> and <task2>
> > in <find> ? I would rather imagine something like :
>
> > <find basedir=... includes=... excludes.../>
> > <task1 ... ${find.file} ${find.dir} ... />
> > <task2 ... ${find.file} ${find.dir} ... />
> [...]
>
> >> Any value?  I haven't coded one up yet.
>
>
> I do not like personally 'find' model to be present in ANT. I like a
> lot, the way processing of my build inputs works currently in ANT - which
> is distinct from traditional 'make' and 'find'-based models.
>
> I cannot see when:
> <task1 ... ${find.file} ${find.dir} ... />
> <task2 ... ${find.file} ${find.dir} ... />
> would be of use?  Everywhere the task can take a list of files, it itself
> implements include/exclude model, like javac/delete etc.  With find we
> would have two ways of doing the same thing, which I feel would break
> the rule of making things simple.  For example if I have to compile
> all my java source files in one directory and then copy them to the
> distribution src directory, in current ANT, with 'no-find-philosophy'
> I do:
>
> 1. compile all java files from _src.dir_
> 2. copy all java files from _src.dir_ to _dist.dir_
>
> with 'find' it usually looks like:
>
> 1. find all the java files from _src.dir_
> 2. compile all what's in ${find.file} ${find.dir}
> 3. copy all what's in ${find.file} ${find.dir} to _dist.dir_
>
> Do not tell me that you do not like the beauty, simplicity and
> the very explicit way of the first (current ANT) model. Everywhere ANT
> lacks the excludes/includes model (like in current exec) it needs
> simple to be extended. Apart from that, in Unix:
>    find <dir> -name <regexp> -exec <task>
> <task> is performed sequentially one call per found item. In most cases
> (like in the one with compiling and copying) you do not want the task
> to be performed n times, once per each found item, you want it to be
> performed once with the list of items (which I suppose the propose
> find task would differ from the real
>       find <dir> -name <regexp> -exec <task> ).
>
> Do not get me wrong, I love 'find', and it would be not possible to
> have 'make' without it, but I am very happy not to have find in ANT,
> and I do not feel the need for it here either. When do you need find
> task to be used? and with what tasks?
>
> -1
>
> regards
> Mariusz
>