ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Assorted comments/bugs re. <zip> and <jar>
Date Thu, 03 Aug 2000 09:22:26 GMT
>>>>> "JG" == Jesse Glick <> 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.


 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^).


View raw message