You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@bost.de> on 2000/06/27 11:34:24 UTC
Possible Exec and MatchingTask Refactorings
Hi,
Just wanted to collect some comments before I start implementing
anything with regard to the subject.
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.
It has been suggested to make Exec extend MatchingTask to account for
this. The two main reasons why I don't like this approach:
* 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).
(3) Run the filenames as the command to execute.
* We would add attributes to tasks that couldn't use them at all. What
would an exclude list mean to an Ant task? This is the same as deriving
Circle from Ellipse.
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.
Comments?
Stefan
Re: Possible Exec and MatchingTask Refactorings
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "MN" == Mariusz Nowostawski <ma...@marni.otago.ac.nz> writes:
>> (3) Run the filenames as the command to execute.
MN> you are serious here?
I am.
In a project I'm contributing to there is a subdirectory named
unittests. Inside of this directory there are small programs each of
which runs a simple test against the recently built system.
Right now I have 54 targets for the 54 single unittests - each with a
single exec inside - and a "runall" target that simply depends on the
other 54. Looks almost like a Makefile.
Stefan
Re: Possible Exec and MatchingTask Refactorings
Posted by Mariusz Nowostawski <ma...@marni.otago.ac.nz>.
Short answer: I like proposed model. +1
What can I do?
Longer:
> 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 <bo...@bost.de>
Reply-To: ant-dev@jakarta.apache.org
To: ant-dev@jakarta.apache.org
Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs Exec.java
Re: Possible Exec and MatchingTask Refactorings
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "TD" == Tom Dimock <ta...@cornell.edu> writes:
TD> The ${} syntax is pretty ugly, but is currently the way ant is
TD> telling the difference between a literal value and a property
TD> reference. How would we do that if we wanted to eliminate ${} ?
I'm afraid this hasn't been resolved yet. The way the if attribute on
nested include tags works is that MatchingTask.NameEntry *knows* the
value is going to be the *name* of a property and can therefore ask
Project for the current - at execution time - value.
There have been thoughts about employing scripts for this purpose. I
don't think this part has really been sorted out yet.
Stefan
Re: Possible Exec and MatchingTask Refactorings
Posted by Tom Dimock <ta...@cornell.edu>.
At 12:43 PM 06/28/2000 +0200, "SB" Stefan wrote:
>>>>>> "TD" == Tom Dimock <ta...@cornell.edu> writes:
>
> TD> At 04:58 PM 06/27/2000 +0200, you wrote:
>
> TD> but not long enough to know what was proposed to replace it....
>
SB>Well, one thing we all seemed to agree on was that properties should
SB>be richer objects, not just Strings, and that the Project would hold a
SB>java.util.Properties like repository of these.
Yes, yes, yes. Or should I say +1 :-)
SB>I've not seen a proposal on how to set these properties with types
SB>other than String so far and in fact I've not seen an alternative to
SB>the ${} syntax. I think the last point should be done by passing the
SB>name of the property to the task and let the task evaluate it - just
SB>like the if/unless attributes of the include/exclude parts in
SB>MatchingTask work.
One problem with XML is that by making all attrubutes quoted, they
eliminated the most conventional way of distinguishing between a literal
and a reference. The ${} syntax is pretty ugly, but is currently the way
ant is telling the difference between a literal value and a property
reference. How would we do that if we wanted to eliminate ${} ?
SB>Your <worklist> would be a way to specify a property with file list
SB>value, right? So how about giving the Property task - it is a Task
SB>implementation after all - MatchingTask behavior?
Yes! Exactly where I was headed. The string-only aspect of properties had
prevented me from doing it the way you suggest, but if we make properties
richer objects, this becomes the way to do it.
SB><property name="files" dir="mybasedir>
SB> <include ... />
SB></property>
SB>
SB>Stefan
SB>
----------------------------------------------------------------------------
Tom Dimock ---- Cornell University ---- tad1@cornell.edu
"There go my people. I must follow them, for I am their leader." M. Gandhi
Re: Possible Exec and MatchingTask Refactorings
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "TD" == Tom Dimock <ta...@cornell.edu> writes:
TD> At 04:58 PM 06/27/2000 +0200, you wrote:
TD> but not long enough to know what was proposed to replace it....
Well, one thing we all seemed to agree on was that properties should
be richer objects, not just Strings, and that the Project would hold a
java.util.Properties like repository of these.
I've not seen a proposal on how to set these properties with types
other than String so far and in fact I've not seen an alternative to
the ${} syntax. I think the last point should be done by passing the
name of the property to the task and let the task evaluate it - just
like the if/unless attributes of the include/exclude parts in
MatchingTask work.
Your <worklist> would be a way to specify a property with file list
value, right? So how about giving the Property task - it is a Task
implementation after all - MatchingTask behavior?
<property name="files" dir="mybasedir>
<include ... />
</property>
Stefan
Re: Possible Exec and MatchingTask Refactorings
Posted by Tom Dimock <ta...@cornell.edu>.
At 04:58 PM 06/27/2000 +0200, you wrote:
>>>>>> "TD" == Tom Dimock <ta...@cornell.edu> writes:
>
> TD> Going in a slightly different direction with this, how about a
> TD> <worklist> task which creates a named list of files?
>
>My main problem with this is that it uses the Property mechanism (and
>even the ${} syntax - but I won't spoil .duncans chance to state his
>opinion on ${} 8^).
I didn't really make myself clear that I was NOT proposing that syntax,
rather I was just trying to get the idea of a worklist out there for
discussion. Such a concept would help make many of my ant build files
simpler. I have been on this list long enough to know that .duncan hates
the ${} syntax, but not long enough to know what was proposed to replace
it....
The main point was that a <worklist> could be used in different attributes
of a task like <exec> to get different behaviors. Having <exec> implement
the matchingtask behavior does lead to the ambiguities you mentioned.
>I'm still not sure what to think of your idea.
Fair enough... :-) It was not too clearly stated!
----------------------------------------------------------------------------
Tom Dimock ---- Cornell University ---- tad1@cornell.edu
"There go my people. I must follow them, for I am their leader." M. Gandhi
Re: Possible Exec and MatchingTask Refactorings
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "TD" == Tom Dimock <ta...@cornell.edu> writes:
TD> Going in a slightly different direction with this, how about a
TD> <worklist> task which creates a named list of files?
My main problem with this is that it uses the Property mechanism (and
even the ${} syntax - but I won't spoil .duncans chance to state his
opinion on ${} 8^).
I'm still not sure what to think of your idea.
Stefan
Re: Possible Exec and MatchingTask Refactorings
Posted by Tom Dimock <ta...@cornell.edu>.
At 11:34 AM 06/27/2000 +0200, Stefan wrote:
>* 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).
>
>(3) Run the filenames as the command to execute.
Going in a slightly different direction with this, how about a <worklist>
task which creates a named list of files? <worklist> would be a
MatchingTask, saving the generated list of files under a name wich could be
referenced similar to a property. Then your three ways become:
(1) <worklist name="myFiles" dir=... includes=... />
<exec command="whatever" dir="${myFiles}" />
(2) <worklist name="myFiles" dir=... includes=... />
<exec command="whatever ${myFiles}" dir="." />
(3) <worklist name="myCmds" dir=... includes=... />
<exec command="${myCmds}" dir="." />
This could then even take your 54 test cases example and run each of them
on you 20 sets of test data:
(4) <worklist name="myCmds" dir=... includes=... />
<worklist name="myFiles" dir=... includes=... />
<exec command="${myCmds}" dir="${myFiles}" />
Of course this is pretty seriously mangling the syntax as shown, but there
has been talk of redoing the ${} syntax anyways....
----------------------------------------------------------------------------
Tom Dimock ---- Cornell University ---- tad1@cornell.edu
"There go my people. I must follow them, for I am their leader." M. Gandhi