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 java.util.zip.*, 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 significantly. - 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. Project.java 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 merits. - 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 defaultManifest.mf 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. Cheers, -Jesse -- Jesse Glick <mailto:[EMAIL PROTECTED]> NetBeans, Open APIs <http://www.netbeans.org/> tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
