It makes sense if you have a few empty directories. But if you have a large directory tree with many files, and many (i.e 50 to 100) empty directories, explictly listing every directory to force it to be included would be a nightmare.
If you check the archives, you'll find there was a time that the zip task did NOT pick up empty directories, and a number of people lobbied for the change in behavior. That change was made, now we all depend on it. If it is removed, it will set us all back a notch or two. Without boring you with details, this issue was sufficiently important to us that we did not even consider adopting ant until the problem was resolved. So obviously, we don't want to see this go away. And, obivously for maintenance reasons, we don't want to have to explictly spell out every empty directory that should be included. What makes more sense to me, if avoiding empty directories is a big issue for others, is to have a property to control this. So just as we can say "compressed=on" or 'compressed=off', we could say "include_empty=on" or 'include_empty=off', with include_empty=on the default. Jesse Glick wrote: > > Ken Wood wrote: > > There are those of us who need these empty directories > > because they are place holders for things to come at > > product install time. So, we need to preserve > > this behavior, especially in zip files, one way or another. > > IMHO: <zip> etc. should create directories for files it is adding, and > empty directories only where explicitly mentioned, e.g.: > > <zip basedir="a"> > <include name="x/"/> > </zip> > > would be the normal case and would give: > > a/x/ > a/x/foo > a/x/bar > > whereas: > > <zip basedir="a"> > <include name="x/"/> > <include name="y"/> <!-- no trailing slash! --> > <include name="z"/> > </zip> > > would mean you explicitly wanted the empty dirs and give: > > a/x/ > a/x/foo > a/x/bar > a/y/ > a/z/ > > Does that make sense? Hopefully this would match behavior of > getIncludedFiles() + getIncludedDirectories(). >
