[PATCH] Assorted fixes and enhancements to and

[Jesse Glick <Je...@netbeans.com>]

A couple of weeks ago I sent out a patch for <zip> and <jar> tasks which
had several enhancements and bugfixes, but did not get any firm response
and it was not applied. There was some disagreement as to handling of
empty archives; so I have created a new patch, which I think resolves
this disagreement by grandfathering the current behavior but making it
easy to switch; and included several more improvements. Attached is a
fresh patch against current CVS sources; noticeable changes from CVS
version in no particular order are:

1. Behavior of Zip and Jar when no files match is more carefully
regulated. (With current CVS sources, it will silently skip making the
archive--not intentionally but due to an improperly swallowed
exception.) There is now an optional attribute "whenempty" which is used
to control what happens when you try to make an archive with no files.
"create" causes it to be created as you asked, though a warning is
printed. "skip" causes it to skip trying to make the archive (and a
warning is printed). "fail" causes the build to halt with an exception.
The default for Zip is "skip" to match current behavior (though
personally I would prefer "fail" or "create" as defaults; it would be a
one-line change to modify the default behavior). The default for Jar is
"create" (since there is always the manifest, so the archive is not
exactly empty). In the case of empty ZIP files, java.util.zip.* cannot
handle this, so an empty ZIP archive (22 bytes, but zero file entries)
is created when "create" is given.

2. Error-handling of both tasks is made more robust; some exceptions
were being swallowed before, or some streams might not have been closed
reliably, etc.

3. Entries for containing directories are added to the archive whenever
files are added, since some tools might fail if these were not present,
and for consistency with existing ZIP and JAR creation tools.

4. The default manifest for JARs says they were created by Ant and gives
the Ant version number used.

5. JARs are recreated if their manifest is specified and is changed on
disk (and of course if any contained files are changed or added too, as
for ZIPs).

6. Documentation update for both tasks covering user-visible changes.

7. Both <zip> and <jar> tasks may take embedded filesets. Thus, for
compatibility with current scripts and for simplicity of syntax, there
is still an implicit fileset used when you specify basedir (which is now
optional if there are embedded filesets). But you may add <fileset> or
<filesetref> elements inside the <zip> or <jar> and these will also be
included in the archive. If multiple filesets are employed, it works
more or less like the JAR tool's -C option: each fileset has its own
basedir, and any files acquired from that fileset are stored with a
relative archive path according to that basedir. This makes it possible
to efficiently and in one task include files from multiple disparate
directories, while controlling the archive path (critical for e.g.
resource paths/packages in JARs).

8. For Jar task, if you have a file META-INF/MANIFEST.MF present in one
of your filesets, this was always ignored in deference to the (automatic
or supplied) manifest. Now a warning is printed if this happens.

Only tested on Linux with Sun JDK 1.3; I tried to not use any > 1.1 APIs
but someone should check of course. Including ZIP of informal test set;
tries to make ZIPs and JARs in various ways with different options. Just
run the build.xml file, target "all" to create; "touchreal" to change
timestamp of a content file, then try "all" again; "touchmani" for a
manifest file; "clean" to delete archives; three other targets mentioned
in it which are expected to fail.

I think that's it. Let me know if anything is missing.

Cheers,
-Jesse

-- 
Jesse Glick   <ma...@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR