ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariusz Nowostawski <>
Subject Re: Possible Exec and MatchingTask Refactorings
Date Tue, 27 Jun 2000 10:00:39 GMT
Short answer: I like proposed model.  +1

What can I do?

> Some of the tasks derived from Exec could benefit from having
> MatchingTask behavior (read work on several files at the same
> time). Chmod and Cvs are two cases, Rmic which could be a subclass of
> Java which in turn extends Exec might be another candidate.

and Exec itself as well.  ;o) I was just about to post it when I have got
your "appendix" Stefan - you're right, WorkOn is fine with me - it is not
necessary Exec which should that sort of job. I am fine with WorkOn being
a subclass of exec and provides matching task behaviour. I am also for a
"flag"...  (I leave the rest as I already typed it in)

> * There are at least three ways I could understand a file list provided
> to a plain exec task:
> (1) Run the command on each of the files - once per file - and always
> add the filename to the command line (probably as the last argument).
> (2) Run the command on all of the files at once - add all filenames as
> arguments to the command line (probably as the last arguments).

Those two cases are both valid and both important, and both should be
taken into considaration, at least for Exec and Java tasks. I do not mind
explicit flag which clearly states which way it will work, once for the
whole list or sequentially call per file.

As far as "(probably as the last argument)" goes, I assume it is very
unlikely (but of course possible) that sombody has to put something after
the file list as an argument. I would forget that case until somebody will
make a good case it is necessary. Then we would have to think about some
sort of simple formatting of the command line arguments
(i.e. command) which is substituting a bit by flie/file list...

> (3) Run the filenames as the command to execute.
you are serious here? ;o)   
exec has a "command" argument which is "the command" to be executed.

All the bellow is perfect for me:

> What I'd prefer to do is to reuse the functionality of MatchingTask
> via delegation. A first draft idea to do so:
> (a) Add an interface MatchingTaskBehavior with setIncludes,
> createInclude ... methods.
> (b) Create a non abstract class MatchingTaskImpl that doesn't extend
> Task but otherwise implements MatchingTaskBehavior the same way
> MatchingTask does right now.
> (c) Make MatchingTask implement MatchingTaskBehavior and delegate all
> methods from the interface to an instance of MatchingTaskImpl.
> (d) Do the same for Cvs and Chmod.

appendix, read message:
Date: 27 Jun 2000 11:51:25 +0200
From: Stefan Bodewig <>
Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs

View raw message