ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gle...@ca.ibm.com
Subject Re: Task functionality next version Ant
Date Mon, 15 May 2000 12:54:04 GMT





There are very good reasons for not using a task attribute to accomplish
two very different purposes.  Unzipping and zipping files are really two
different tasks - related, but different.  If you use an attribute to
determine which task you are actually acomplishing, it can make it harder
to debug.  Its a form of wishy-washy input.  Separate zip and unzip,
copyfile and copydir, tar and untar, etc. tasks are unambiguous in their
purpose.

My $0.02.

Glenn McAllister
TID - Software Developer - VisualAge for Java
IBM Toronto Lab, (416) 448-3805
"An approximate answer to the right question is better than the
right answer to the wrong question." - John W. Tukey


Please respond to ant-dev@jakarta.apache.org

To:        ant-dev@jakarta.apache.org
cc:
Subject:        Re: Task functionality next version Ant


>>>>> "KA" == Kuiper, Arnout <Arnout.Kuiper@nl.origin-it.com> writes:

 >> > -----Original Message----- > From: Stefan Bodewig

 >> > The optional RenameExtensions tasks lokks a little bit as if it
>> > belonged into the move category.

 KA> Could be, but it is a bit tricky.

 KA> If we want to include the "RenameExtensions" functionality in
KA> "Move", than I propose to make it more general, and allow to
KA> change filenames (pathnames?) with the use of some regexp.

Hope we are not approaching Perl here 8^). Pathnames would really be
too much I guess.

And once you open up the box with regexps here you will probably need
something like "calculated replacements" for the patterns -
i.e. something like Perl's s/(\w+)/lc($1)/ge that would then change all
filenames to be all lowercase etc.

I'm sure something like this would be useful for some people. But you
are right, this functionality should be separated into a different
task - which doesn't need to be part of the core anyway.

 >> > Expand and Zip could be put together into a single task.

 KA> Personally I would keep these separated (and rename expand to
KA> unzip). The same holds for jar and unjar and gzip and gunzip.

as well as tar and untar.

AFAIK zip is currently the only "compression" operation with a task
for decompression. I thought after putting together expand and zip
into one task we could have a consistent interface for the other
tasks, something like a boolean "expand" attribute.

If we'll keep expand (I'd prefer the name unzip in this case as well)
and zip as different tasks then we should implement all the reverse
tasks as tasks of their own as well.

Stefan




Mime
View raw message