Ah, I see. This does look like a bug.
I was about to say only the date of the zip file is used for dependency checking, but this is not the case, so any names that are not in the filesets could be used to trigger a new zip file when update="false".
Peter Yves Martin wrote:
In fact, my test does not reproduce the issue correctly:
Replace your first zip by:
<zip destfile="newfile.zip" whenempty="create" duplicate="fail" update="false"> <fileset dir="." includes="file1,file2,file3"/> </zip>
So here is the issue:
- if selected files are up-to-date in an existing zip, the file is not rebuild BUT it may contains unwanted files !!!
I do not know if we can consider it a "feature" - so to document - or a bug...
But the result is strange:
- if the zip does not exist yet, it only contains file1,file2
- if the zip already exists (maybe with too many files), its content is unchanged.
In my case, it is really annoying: if you change excludes filters with an already generated zip - the contain "remains", so the result is wrong...
Regards,
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
