ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glenn McAllister/Toronto/IBM" <gle...@ca.ibm.com>
Subject Re: [PATCH] Consolidated copy, move, and delete tasks
Date Wed, 13 Sep 2000 19:00:56 GMT
I was trying to keep the way copy, delete, and move worked consistent so I 
figured either they all have an implicit fileset or none of them do.  The 
consensus (sp?) way back when was to _not_ have an implicit fileset, so I 
went with that.  Should we make all three have the implicit fileset?  So 
we get

<copy dir="blah" todir="otherblah" includes="*.html">
  <include name="**/*.css" />
  <exclude name="**/*.htm" />
  <fileset dir="yet_another_blah">
    <include name="**/yadda_yadda.*" />
  </fileset>
</copy>

I was trying to stay away from this, because it looks a bit sloppy to me. 
That being said, I'm happy to temporarily use the implicit fileset for 
delete to maintain current functionality, and remove it after the next 
release.

The copy task does have the flatten attribute.  In point of fact, so does 
the move task.  Move inherits from copy, the only difference is that once 
the copy is complete, move deletes the original file.  Oh, and to 
overwrite existing files is the default.  So, we get all the same 
features, including flattening, filtering, and overwrite.

The delete task using the dir attribute does actually delete the 
directory.  I didn't make that explicit in the examples, as I figured that 
most people would assume that's the default behaviour.  I called it out in 
move because there is the chance someone would assume that the files under 
the directory are to be moved, not the directory itself.

To delete empty directories when using filesets in the delete task, I 
could walk the tree of included directories and attempt to delete them. 
However, this behaviour might best be triggered with an attribute (<delete 
removeEmpty="yes" ...>) because I seem to recall people wanting to delete 
all the files in a directory tree, but keep the tree around.

Glenn McAllister
Software Developer. 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: [PATCH] Consolidated copy, move, and delete tasks

>>>>> "gm" == glennm  <glennm@ca.ibm.com> writes:

 gm> The biggest difference between these tasks and the current
 gm> delete, deltree, copyfile, and copydir tasks is that the fileset
 gm> is _not_ implicit.  The drawback to this is that it breakes
 gm> existing delete functionality.  The advantage is clarity and
 gm> consistency in the use of filesets.

Any chance to temporarily keep the old behavior within <delete>
(i.e. add an implicit fileset to <delete> and only to <delete>)?

I have no problem removing deprecated things - nothing that has been
deprecated in Ant 1.1 is still present. But if possible we should keep
build files, that were perfectly well adapted to Ant 1.1, working.

I'd propose to add an implicit fileset to delete, emit deprecation
warnings if it is used and remove it right after the next release.

 gm> I'm affraid I deleted the email where Conor explained how to
 gm> include new files in a patch,

Trick CVS into thinking the file has been added (i.e. add an entry for
each file to the corresponding CVS/Entries file).

 gm> Copy

Let's keep the flatten attribute. At least one guy out there seems to
need it 8^).

 gm> Move [...]

 gm> Note that the above move will actually remove the "directory"
 gm> subdirectory of "original".

Is it consistent for <move> to remove (empty) directories but <delete>
to keep them?

Stefan

- who hasn't found time to actually read your code yet.


Mime
View raw message