ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mariusz Nowostawski <mari...@marni.otago.ac.nz>
Subject [patch] Proposal for refactoring
Date Thu, 20 Jul 2000 02:41:17 GMT
I have prepared simple patch for refactoring of current
ExecTask and ExecuteOn. The patch will remove all duplicated code from
current draft of ExecuteOn, and will slighlty modify ExecTask to be more
"subclasses-friendly".   This is just a proposal, have a look and decide.

It produces exactly the same result as Stefan "ls -l" snapshot (with the
small difference in the file sizes and lack of one ~ file ;o)


How about making <executeon> shorter: <execon>
and making the class ExecOnTask ?  I don't really care about the names,
but I suspect it would be good to be as consistent as
possible. Or maybe making 'exec' 'execute' ... Suggestions?

In types/Commandline.java there is a method called addLine(String[]).
What about renaming it to addLines(String[]) or, putting second method
addLine(String)?   At first addLine was to me a little confusing not to
accept single String argument.  Of course, once I had a look into the
source it was fine, but maybe plural or additional version of it will be
more 'newcomer'-friendly, what do you think.

I think with the patch all three points made by Stefan in previous post
are solved, but I have not tested it that much yet though.  As I said, it
is just a proposal...

In Stefan's implementation there was forking a seperate executable for
single file argument in a big loop. This is referred as 'sequential'
execution. In the patched version, all arguments are passed to the single
executable call, so the process is forked once for all of the files. This
is referred as parallel execution.  I think that parallel execution should
be the default, because of huge performance difference, and because I have
tried to come up with the executables which take single file as an
argument only, and I could not come up with one - I suspect there are
cases out there in which sequential execution might be essential, but 
majority of uses is fine with the parallel one.  If there is a need for
sequential mode, we might control it by seperate task, or by additional
attribute, but to to so (at least I) need a single case when it might be
essential. Personally for me it is not (at the moment ;o).


cheers
Mariusz

Mime
View raw message