On 5/8/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
OK, now I'm pretty confident everything's working as expected.
*chuckle* so now that we're on even footing...;)
Desired outcome: > files test/something.ini, test/test1/test2/another.ini deleted > dirs test3 and test2 deleted as both are now empty. test3 *would* be deleted if you included it somehow. One way would be to have an <emptydir /> file selector, which would additionally and optionally recognize the recursive case when a dir contains only "empty" dirs because they contain only empty dirs, etc... test2 OTOH would never be deleted because it *becomes* empty after the fact. 2 <delete> could work around that, at the expense of a second scan.
Right - but if you use an <exclude>, it *does* delete test2 - hence the frustration. In theory, from a usage standpoint, it would stand to reason that using includeemptydirs should work similarly regardless of whether or not you have an <include> in your <fileset>, yes? As it stands in the current implementation, even with <emptydir />, they do not. What you want is actually implemented (originally by me ;-) in <sync>,
which removes empty dirs (recursively) in a 3rd pass, once files have been added and removed... But that's not <delete>
So one could theoretically call <delete> then <sync> in a task? That's cool, but...it would still seem like <delete> *should* be able to optionally do that itself.
Using an excludes pattern [...], it does exactly as desired, > but it's kind of hacky as you have to think backwards Agreed. --DD
So I return to the question of, is there any good reason why the implementation can't change? -Liz -- Imagination is intelligence having fun... [EMAIL PROTECTED]
