https://issues.apache.org/bugzilla/show_bug.cgi?id=47373
--- Comment #15 from Jesse Glick <[email protected]> 2009-06-22 09:49:07 PST --- I will repeat my advice that the new feature be added to ArchiveFileSet, not any Task impl such as Zip. Ant already includes the ability to configure various things on an ArchiveFileSet which would override values otherwise inferred from File inputs, and the existing 'filemode' (or 'dirmode') attr most closely resembles the proposed timestamp. As to the objection that existing users of <zip> etc. do not always use <zipfileset> - well if they wish to change the behavior of the task to specify a timestamp, then they need to change their build script somehow. Replacing <fileset> with <zipfileset> (in addition to specifying the timestamp attr) does not seem to me to be a burden. A complete patch along the lines I recommend would involve changes to: - ArchiveFileSet: XML-configured setter for timestamp, something along the lines of your current patch, plus a getter (for a Long?) - Zip: addResources should when checking "if (fileset instanceof ArchiveFileSet)" also check for the timestamp, and subsequent calls to zipFile and addParentDirs methods should be modified to use that timestamp if specified - Tar: tarResource should, if tarFileSet != null, call te.setModTime with the specified time if set (rather than using r.getLastModified()) (Note: it would be much cleaner if ArchiveFileSet would _always_ create custom resources (even when src==null), so that these ArchiveResource's could specify their own mode, last mod time, etc., and tasks like Zip and Tar would not need hacks like doing runtime type checks on the fileset - so would not need to be patched at all to support a feature like this. But probably too late for such a change.) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
