>>>>> "JG" == Jesse Glick <[EMAIL PROTECTED]> 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
