You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Liz Burke-Scovill <fi...@gmail.com> on 2006/05/08 19:09:50 UTC
Bringing up an old issue that was never addressed: includeemptydirs on delete
Hi, I'd like to ask the best way to address this issue. It was originally
brought up in bug report 36048,
http://issues.apache.org/bugzilla/show_bug.cgi?id=36048 , I'm bring it up
here as opposed to user@ant.apache.org, because I see this more as a further
discussion of a task already in bugzilla as opposed to a usage question.
The issue is that when includeemptydirs is set to "true" on a delete, it
does not appear to work. The first reply indicates that since the patternset
does not include directories, so the directories should not be deleted. I
disagree as it would seem that that would defeat the purpose of having an
optional flag to include empty directories.
I have also found that includeemptydirs works as indicated when an excludes
attribute or exclude node is used with the fileset. For example:
<delete includeemptydirs="true">
<fileset dir="foo" excludes="**/*.bar" />
</delete>
In this example, it deletes all empty directories. Using false does not
delete empty directories, and as such it works as expected. The following
example:
<delete includeemptydirs="true>
<fileset dir="foo" includes="**/*.bar" />
</delete>
behaves no differently regardless of whether or not includeemptydirs is set
to true or false. Therefore, either documentation needs to indicate this
behavior, or it should be considered a bug (feature? ;) ) and assigned (I'd
be willing to look at code to work on it).
Additionally, if a delete task with includeemptydirs="true" has both
excludes and includes in its filesets, the behavior displayed is the same as
the second example.
The reason I bring this up here is to further discussion. Is there a reason
that includeemptydirs acts this way with includes? Or is it something that
was overlooked?
Thanks!
Liz Burke-Scovill
--
Imagination is intelligence having fun...
fiddledragon@gmail.com
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Liz Burke-Scovill <fi...@gmail.com>.
>
> If I was understanding the test2 scenario correctly,
> i.e. test2 doesn't get deleted because it's not empty
> until test3 is deleted for being empty, I *think* this
> will work as expected in HEAD. I did some things in
> there specifically to sort directories such that
> children would be encountered before their parents
> IIRC. And I seem to remember thinking that something
> related to this would delete more than the current
> release.
>
> -Matt
>
Matt,
FWIW - it did work as expected in my test script locally using 1.6.5 on
Windows XP - I'm about to test it also using 1.6.5 on Solaris in a more real
world situation.
I have no idea as to it's applicability in HEAD as I won't be able to look
at the subversion repositories until this evening when I get home.
-Liz
--
Imagination is intelligence having fun...
fiddledragon@gmail.com
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Dominique Devienne <dd...@gmail.com>.
> might work as expected in HEAD. I did some things in
> there specifically to sort directories such that
> children would be encountered before their parents
> IIRC. And I seem to remember thinking that something
> related to this would delete more than the current release.
Hmm, that would be breaking BC in a good way, then, no? ;-) --DD
PS: I'd also expect the added sort to slow things down a tiny bit,
but processing the children before the parents sounds like a good idea.
If nothing came up thru Gump, this should be safe enough.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Liz Burke-Scovill <fi...@gmail.com>.
On 5/8/06, Dominique Devienne <dd...@gmail.com> wrote:
>
>
> That's a good solution Matt. Gets rid of test3.
Thank you to both of you :)
FTR, I'm a strong proponent of generating all build output into a
> single dir (I use the build/ dir myself), and never anywhere in the
Agreed. Unfortunately I don't get to decide that. I just get to work with
what I'm given :P
Thanks again!
Liz
--
Imagination is intelligence having fun...
fiddledragon@gmail.com
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Matt Benson <gu...@yahoo.com>.
--- Dominique Devienne <dd...@gmail.com> wrote:
> > <delete includeemptydirs="true">
> > <fileset dir="test">
> > <or>
> > <filename name="**/*.ini" />
> > <type type="dir" />
> > </or>
> > </fileset>
> > </delete>
>
> That's a good solution Matt. Gets rid of test3.
If I was understanding the test2 scenario correctly,
i.e. test2 doesn't get deleted because it's not empty
until test3 is deleted for being empty, I *think* this
will work as expected in HEAD. I did some things in
there specifically to sort directories such that
children would be encountered before their parents
IIRC. And I seem to remember thinking that something
related to this would delete more than the current
release.
-Matt
>
> FTR, I'm a strong proponent of generating all build
> output into a
> single dir (I use the build/ dir myself), and never
> anywhere in the
> source tree or any dir under SCM, so I never have to
> pick and choose
> what to delete and how. I just nuke that one dir to
> remove all
> generated build products (clean target), with no
> fear to delete by
> mistake other files. --DD
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Dominique Devienne <dd...@gmail.com>.
> <delete includeemptydirs="true">
> <fileset dir="test">
> <or>
> <filename name="**/*.ini" />
> <type type="dir" />
> </or>
> </fileset>
> </delete>
That's a good solution Matt. Gets rid of test3.
FTR, I'm a strong proponent of generating all build output into a
single dir (I use the build/ dir myself), and never anywhere in the
source tree or any dir under SCM, so I never have to pick and choose
what to delete and how. I just nuke that one dir to remove all
generated build products (clean target), with no fear to delete by
mistake other files. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Matt Benson <gu...@yahoo.com>.
--- Liz Burke-Scovill <fi...@gmail.com> wrote:
[SNIP]
> XML snippet:
>
> <delete includeemptydirs="true">
> <fileset dir="test" includes="**/*.ini" />
> </delete>
>
> Actual outcome:
>
> test/something.ini and test/test1/test2/another.ini
> are deleted - this is
> also expected based on current implementation.
>
> Desired outcome:
>
> files test/something.ini,
> test/test1/test2/another.ini deleted
> dirs test3 and test2 deleted as both are now empty.
>
> Using an excludes pattern of <fileset dir="test"
> excludes="**/*.txt" />, it
> does exactly as desired, but it's kind of hacky as
> you
> have to think backwards, and if you have more than
> one filetype, it will get
> more complicated...and what if (as in our real world
> situation) files of
> various and changing file types are being added, and
> we *only* want to
> delete one specific file type. In an automated build
> situation, we as
> developers shouldn't care what other file types
> other developers are adding
> if we *only* want to delete say class files.
>
>
Liz: I don't think this will be resolved to your
complete satisfaction. :( Occasionally there are
multiple ways of thinking about a given problem and it
can be difficult to reconcile contrary points of view.
The behavior you are asking for opposes Ant's basic
concept of fileset-based tasks. The following is
about the best compromise this discussion is likely to
arrive at:
<delete includeemptydirs="true">
<fileset dir="test">
<or>
<filename name="**/*.ini" />
<type type="dir" />
</or>
</fileset>
</delete>
HTH,
Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Liz Burke-Scovill <fi...@gmail.com>.
On 5/8/06, Dominique Devienne <dd...@gmail.com> 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...
fiddledragon@gmail.com
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Dominique Devienne <dd...@gmail.com>.
OK, now I'm pretty confident everything's working as expected.
> 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.
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>
> Using an excludes pattern [...], it does exactly as desired,
> but it's kind of hacky as you have to think backwards
Agreed. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Liz Burke-Scovill <fi...@gmail.com>.
On 5/8/06, Dominique Devienne <dd...@gmail.com> wrote:
>
> Liz, I'm still not 100% sure I understand your use case now ;-)
>
> Would you mind providing a simplified sample listing of the files in
> your directory before <delete>, the XML snippet for the <delete> tag
> with its nested elements you're using, and which files you expect to
> get deleted?
sure - though expect is loaded. Again - this is what I would *expect* based
on perceived usage - rather than implemented logic. Does that make sense? I
understand what delete currently does...and technically how it does it.
That's not the problem. The problem is now discussing whether or not delete
could be implemented such that includeemptydirs actually has meaning for
both includes and excludes, if that makes sense? Right now in the current
implementation, includeemptydirs has no functional meaning, unless you
happen to have a patternset that includes the name of the directory/ies in
question....I'm talking about cleaning up empty dirs when doing a delete.
Before <delete>:
test/something.ini
test/test1/
test/test1/document.txt
test/test1/test2
test/test1/test2/another.ini
test/test1/test2/test3/
XML snippet:
<delete includeemptydirs="true">
<fileset dir="test" includes="**/*.ini" />
</delete>
Actual outcome:
test/something.ini and test/test1/test2/another.ini are deleted - this is
also expected based on current implementation.
Desired outcome:
files test/something.ini, test/test1/test2/another.ini deleted
dirs test3 and test2 deleted as both are now empty.
Using an excludes pattern of <fileset dir="test" excludes="**/*.txt" />, it
does exactly as desired, but it's kind of hacky as you
have to think backwards, and if you have more than one filetype, it will get
more complicated...and what if (as in our real world situation) files of
various and changing file types are being added, and we *only* want to
delete one specific file type. In an automated build situation, we as
developers shouldn't care what other file types other developers are adding
if we *only* want to delete say class files.
I'm a bit puzzled that you mention that your empty dirs seem selected
> by looking at the debug output, yet are not deleted. --DD
>
No, you're right, they don't seem to be selected, but that's based on
current implementation. However, the debug output only shows the end result,
not the initial matches before includes or excludes (which would also be
nice).
Thanks!
Liz
--
Imagination is intelligence having fun...
fiddledragon@gmail.com
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Dominique Devienne <dd...@gmail.com>.
Liz, I'm still not 100% sure I understand your use case now ;-)
Would you mind providing a simplified sample listing of the files in
your directory before <delete>, the XML snippet for the <delete> tag
with its nested elements you're using, and which files you expect to
get deleted?
I'm a bit puzzled that you mention that your empty dirs seem selected
by looking at the debug output, yet are not deleted. --DD
On 5/8/06, Liz Burke-Scovill <fi...@gmail.com> wrote:
> On 5/8/06, Dominique Devienne <dd...@gmail.com> wrote:
> >
> > In your first example, your empty dirs are implicitly included, and
> > and later not excluded, so <delete> will get rid of them.
> >
> > In your second example, your include pattern prevent the empty dirs
> > from being selected, because they don't match your pattern, so they
> > can't be deleted (the exclude patterns don't matter).
>
>
> *nod* Which I'd thought about - however, then, it would appear that the
> *only* point to "includeemptydirs" is that it's used as a flag to indicate a
> false condition and only usable in the event that an exclude patternset is
> present. In that case, it should be documented as such...and it probably
> should have been named "excludeemptydirs" ;)
>
> The fact that some directories might become empty once all the files
> > you wanted deleted are gone is of no concern to <delete>, as currently
> > implemented.
>
>
> *grin* _as currently implemented_ being the point. My question more revolves
> around the necessity of it being implemented this way - which doesn't seem
> to make much sense from a usage standpoint, even if it makes sense logically
> from an implementation standpoint.
>
> <delete> only concerns itself with the files (files or dirs) selected
> > by the filesets it operates upon, so if the "empty" dirs you want
> > deleted are not listed by these filesets (use debug mode to see the
> > files selected), they won't be deleted.
>
>
> *nod* debug does list the files selected, but it doesn't open up the logic
> behind it. I can't get subversion to access the latest code at the moment
> due to firewall policies, so I'll try and look at it this evening to get a
> clearer understanding of the hows and whys.
>
> Why is this important? (At least to me - and at least one other person ;) )
> In the situation where you are trying to clean up a tree, and an inclusion
> patternset is the most reasonable way to go, you still want to be able to
> clean up empty directories rather than letting them stand. I'm sure there
> are other reasons, but this one is the most relevant to my current
> situation. Using an exclusion pattern set would probably work, but it would
> be somewhat hacky considering that simply based on naming conventions, using
> an includeemptydirs would just make sense.
>
> Thank you!
> Liz
>
>
>
>
>
> --
> Imagination is intelligence having fun...
> fiddledragon@gmail.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Liz Burke-Scovill <fi...@gmail.com>.
On 5/8/06, Dominique Devienne <dd...@gmail.com> wrote:
>
> In your first example, your empty dirs are implicitly included, and
> and later not excluded, so <delete> will get rid of them.
>
> In your second example, your include pattern prevent the empty dirs
> from being selected, because they don't match your pattern, so they
> can't be deleted (the exclude patterns don't matter).
*nod* Which I'd thought about - however, then, it would appear that the
*only* point to "includeemptydirs" is that it's used as a flag to indicate a
false condition and only usable in the event that an exclude patternset is
present. In that case, it should be documented as such...and it probably
should have been named "excludeemptydirs" ;)
The fact that some directories might become empty once all the files
> you wanted deleted are gone is of no concern to <delete>, as currently
> implemented.
*grin* _as currently implemented_ being the point. My question more revolves
around the necessity of it being implemented this way - which doesn't seem
to make much sense from a usage standpoint, even if it makes sense logically
from an implementation standpoint.
<delete> only concerns itself with the files (files or dirs) selected
> by the filesets it operates upon, so if the "empty" dirs you want
> deleted are not listed by these filesets (use debug mode to see the
> files selected), they won't be deleted.
*nod* debug does list the files selected, but it doesn't open up the logic
behind it. I can't get subversion to access the latest code at the moment
due to firewall policies, so I'll try and look at it this evening to get a
clearer understanding of the hows and whys.
Why is this important? (At least to me - and at least one other person ;) )
In the situation where you are trying to clean up a tree, and an inclusion
patternset is the most reasonable way to go, you still want to be able to
clean up empty directories rather than letting them stand. I'm sure there
are other reasons, but this one is the most relevant to my current
situation. Using an exclusion pattern set would probably work, but it would
be somewhat hacky considering that simply based on naming conventions, using
an includeemptydirs would just make sense.
Thank you!
Liz
--
Imagination is intelligence having fun...
fiddledragon@gmail.com
Re: Bringing up an old issue that was never addressed: includeemptydirs on delete
Posted by Dominique Devienne <dd...@gmail.com>.
Yes, this is by design, counter-intuitive as it may seem ;-)
With no include patterns, the filesets selects *all* files under the
given directory, i.e. any file (isDirectory() == false) or directory
(isDirectory() == true), and then trims this list using the exclude
patterns.
In your first example, your empty dirs are implicitly included, and
and later not excluded, so <delete> will get rid of them.
In your second example, your include pattern prevent the empty dirs
from being selected, because they don't match your pattern, so they
can't be deleted (the exclude patterns don't matter).
The fact that some directories might become empty once all the files
you wanted deleted are gone is of no concern to <delete>, as currently
implemented.
<delete> only concerns itself with the files (files or dirs) selected
by the filesets it operates upon, so if the "empty" dirs you want
deleted are not listed by these filesets (use debug mode to see the
files selected), they won't be deleted.
Does this help? Thanks, --DD
On 5/8/06, Liz Burke-Scovill <fi...@gmail.com> wrote:
> Hi, I'd like to ask the best way to address this issue. It was originally
> brought up in bug report 36048,
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36048 , I'm bring it up
> here as opposed to user@ant.apache.org, because I see this more as a further
> discussion of a task already in bugzilla as opposed to a usage question.
>
> The issue is that when includeemptydirs is set to "true" on a delete, it
> does not appear to work. The first reply indicates that since the patternset
> does not include directories, so the directories should not be deleted. I
> disagree as it would seem that that would defeat the purpose of having an
> optional flag to include empty directories.
>
> I have also found that includeemptydirs works as indicated when an excludes
> attribute or exclude node is used with the fileset. For example:
>
> <delete includeemptydirs="true">
> <fileset dir="foo" excludes="**/*.bar" />
> </delete>
>
> In this example, it deletes all empty directories. Using false does not
> delete empty directories, and as such it works as expected. The following
> example:
>
> <delete includeemptydirs="true>
> <fileset dir="foo" includes="**/*.bar" />
> </delete>
>
> behaves no differently regardless of whether or not includeemptydirs is set
> to true or false. Therefore, either documentation needs to indicate this
> behavior, or it should be considered a bug (feature? ;) ) and assigned (I'd
> be willing to look at code to work on it).
>
> Additionally, if a delete task with includeemptydirs="true" has both
> excludes and includes in its filesets, the behavior displayed is the same as
> the second example.
>
> The reason I bring this up here is to further discussion. Is there a reason
> that includeemptydirs acts this way with includes? Or is it something that
> was overlooked?
>
> Thanks!
> Liz Burke-Scovill
>
> --
> Imagination is intelligence having fun...
> fiddledragon@gmail.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org