Assorted comments/bugs re. and

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

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

Re: Assorted comments/bugs re. and

[Stefan Bodewig <bo...@bost.de>]

>>>>> "JG" == Jesse Glick <Je...@netbeans.com> writes:

 JG> Conceivably it may be worthwhile to have a special attribute for
 JG> <zip> and <unzip> which if set, and if running on Unix, would
 JG> first try to run a "zip" or "unzip" program

The same would hold true for <tar> - which is very likely to be found
on Unix systems.

 JG> - ZIP and JAR tasks could support filtering.

One of the realy bad side effects of filtering is, that it will
corrupt your binary files (like images) - at least as it is
implemented right now. This should probably be fixed anyway.

I'm not that fond of filtering at all.

 JG> - Would be nice to support appending to an existing ZIP, or
 JG> instead permitting you to specify multiple base dirs (I guess
 JG> this would mean filesets).

Yes, I've been meaning to rewrite most of the MatchingTask subclasses
to support multiple filesets sometime. But I won't get there soon.

 JG> - The zip/jar up-to-date check does not rebuild the archive if
 JG> some source files are *removed* (vs. added or modified).

To really do it's job correctly it shouldn't compare the date of the
files to store with the date of the archive anyway, but look at the
timestamps on the entries inside the ZIP file.

 JG> [...] which is probably more overhead than this merits.

8^)

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

Fixed in CVS.

 JG> Sorry this was a mouthful,

I like most of your ideas, feel free to submit patches 8^).

Stefan