ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liz Burke-Scovill" <>
Subject Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Date Mon, 08 May 2006 20:35:00 GMT
On 5/8/06, Dominique Devienne <> 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, 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?


Imagination is intelligence having fun...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message