OK,
for the test cases that are there, this bug is fixed. But I'm rather
sure that the tests are not good enough 8-)
I think it will fail for <zipfileset>s with <excludes> (will update
even when it shouldn't) and probably in some cases for <excludes> on
the "implicit" fileset - I'll try to come up with testcases for this,
to back the claims.
Beyond what Antoine and myself had been talking about I had to put in
an additional change without which the <jar> tests would fail
randomly:
ZIP archives store file modification times with a granularity of two
seconds. Our ZipOutputStream used to round this down to the next
lower even number. This in turn means that many times the zip entry
for a file is older than the file itselt, leading to the old "always
updates" behavior for these cases.
I've now changed the code to round up to the next higher even number,
this in turn means that we will miss some updates in border cases, but
I had to make a choice.
One thing that has to be addressed for bc is that Zip#isUpToDate has
changed its signature. I think this can be solved by adding
// old signature
protected boolean isUpToDate(FileScanner[] scanners, File zipFile)
throws BuildException {
return true;
}
and at the top of the new isUpToDate() method add
protected boolean isUpToDate(ResourceScanner[] scanners,
FileSet[] fss, File zipFile)
throws BuildException {
if (!isUpToDate(scanners, zipFile)) {
return false;
}
This would allow existing subclasses to have their isUpToDate method
called, but they'd no longer be able to suppress the check in Zip
completely. This certainly warrants a warning in WHATSNEW.
Anyone with a better idea?
Then there are a couple of nits like "Should Resource#isExists better
be Resource#exists?". I'll leave it to this list to review and refine
what we have. Once we are happy, I volunteer to merge the changes
into the 1.5 branch.
Stefan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
