ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Assorted comments/bugs re. <zip> and <jar>
Date Wed, 02 Aug 2000 18:53:43 GMT
This is sort of a grab bag but:

- The docs for <zip> and <jar> (but mostly <zip>) should point out that
file execute permissions will not be stored on Unix. In fact they cannot
be, using*, since (1) there is no API support for it and
(2) there is no way to even tell whether a file is executable from
within Java. But the docs should mention this. Also for <unzip>, that it
will not set the permissions.

Conceivably it may be worthwhile to have a special attribute for <zip>
and <unzip> which if set, and if running on Unix, would first try to
run  a "zip" or "unzip" program instead of doing it from Java; if no
such program is found, print a warning. (The native programs will
correctly handle --x bit.) But this would complicate things

- ZIP and JAR tasks could support filtering. I don't think it would be
unreasonable, since the code really goes and opens every file, so it
could just as easily apply token filtering to them. would
need to make the filtering code a little more accessible, since it needs
a filtering input stream, not just copying a file.

- Would be nice to support appending to an existing ZIP, or instead
permitting you to specify multiple base dirs (I guess this would mean
filesets). (I remember someone mentioning they had a standalone utility
to do something similar.) Otherwise you would need to merge several
directories together and then zip the result, which is needless
overhead. Compare "jar" utility's -C option.

- The zip/jar up-to-date check does not rebuild the archive if some
source files are *removed* (vs. added or modified). I guess this is true
also of other targets, though it seems more clearly incorrect in this
case since the only contents of the archive should be what you specified
to the task. However a fix would mean opening and scanning the existing
ZIP to see what it contained, which is probably more overhead than this

- The <jar> task just sticks the supplied manifest into the JAR
verbatim, which *technically* can result in an incompliant JAR since it
does not (1) ensure that Manifest-Version: 1.0 is present and (2) does
not do line-wrapping after 72 characters. I don't know of anything which
actually chokes because of these things, but anyway the JDK jar tool
does this stuff as a matter of course. Naturally you are free to write
compliant input manifests to begin with.

- For <jar>, the should maybe say "Created-By: Ant",
just for fun.

- <jar> again: if a manifest was specified, but META-INF/MANIFEST.MF was
present in the included file list, that should probably be an error, not
silently ignored.

- <jar>: the up-to-date check does not take into account the supplied
manifest file's timestamp (if there is one).

- <jar>: if the manifest file is not found, it throws an error, but then
leaves behind an empty .jar with a current timestamp. This causes
subsequent builds to think that the .jar is up-to-date.

Sorry this was a mouthful, but in the absence of a formal bugtracking
system these things tend to accumulate...BTW I use Ant 1.1 release, it
is possible some of these things have been fixed since then.


Jesse Glick   <>
NetBeans, Open APIs  <>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

View raw message