[PATCH] PrefixFileSets

["Rosen, Alex" <ar...@silverstream.com>]

Pete, those changes look good to me. I do have a few suggested fixes to the new
code. I created two levels of changes. The first batch (ZipDiff1.txt) contains
just bugfixes, which I think should be non-controversial. The second batch
(*Diff2.txt) changes the behavior, adding some functionality that I think is
useful. It also reorganizes the code somewhat, removing most of the code from
Jar and War. I think these are all good changes, but I'll leave it up to you to
decide which batch to take.

Enjoy!
Alex

[BATCH 1]

- execute() now checks for (locFileSets.size() == 0) too, so if your Zip task
contains only prefixedfilesets, it won't throw an exception.

- If your build file included a <prefixedfileset> that didn't contain a
"prefix" attribute, the directory "" would get added to the archive, which is
OK with WinZip, but the "jar" tool chokes on it. Now "" never gets added.

- All the parent directories of the prefix directory were not being added to
the archive. E.g. if the prefix was "x/y/z", then directory "x/y/z" was added,
but not "x/y" or "x". Don't know why this is important, but other parts of
Zip.java seem to think it is. Now all parent directories are added.

- Fixed a comment to say "prefixedfileset" instead of "relocatablefileset"
(must have been a previous name).

- Fixed the exception handling in execute(). Previously, if for example your
<war> element didn't have a "webxml" element, you'd get this exception:

Problem creating war: ZIP file must have at least one entry (and the archive is
probably corrupt but I could not delete it)
java.util.zip.ZipException: ZIP file must have at least one entry

That's because close() in the finally clause was throwing a second exception,
and the real problem (the BuildException that happened before that) was getting
lost. It now swallows the close() exception (when necessary), and displays the
real problem instead ("webxml attribute is required").

[BATCH 2]

- PrefixedFileSet now has an additional attribute "fullpath", which specifies
the full path in which to save the file specified by the fileset. For example,
fullpath="META-INF/MANIFEST.MF". This means that the name of the file can be
changed when it goes in the archive, not just the path. This attribute is only
valid on a fileset that represents a single file. (As I mentioned in an earlier
e-mail, I think I prefer "archivedir" and "archivefile" to "prefix" and
"fullpath", but I've left them as-is for now.)

- A big benefit of this change is that it now allows Jar, War, and other
potential subclasses, to just be special cases of Zip. Most of the code in Jar
and War goes away - they just perform some setup, turing the "manifest"
attribute (for example) into a PrefixedFileSet with
fullpath="META-INF/MANIFEST.MF". Other subclasses such as Ear can be added with
a minimum of code, but the nice thing is that they're not required anymore -
you can get the same functionality just by setting up your <zip> task, rather
than having to write an Ear task.

- I changed the name of the add method, so that you now use regular <fileset>
elements instead of <prefixedfileset> elements. I think this is better, but it
can easily be changed.

Re: [PATCH] PrefixFileSets

[Peter Donald <do...@apache.org>]

At 12:11  8/12/00 -0500, you wrote:
>Pete, those changes look good to me. I do have a few suggested fixes to
the new
>code. I created two levels of changes. The first batch (ZipDiff1.txt)
contains
>just bugfixes, which I think should be non-controversial. The second batch
>(*Diff2.txt) changes the behavior, adding some functionality that I think is
>useful. It also reorganizes the code somewhat, removing most of the code from
>Jar and War. I think these are all good changes, but I'll leave it up to
you to
>decide which batch to take.

thanks !

Diff1 applied. Does anyone else have any problems with *Diff2? I am +1 on
the mods.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*