ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Need some advice: Zip/Jar/Ear/War API backwards incompatibilities
Date Tue, 04 Feb 2003 13:39:02 GMT
Hi all,

it seems impossible to get bug 10755 fixed without modifying the
signature of at least isUpToDate in Zip.java in a way that would
keep subclasses working without modification.

The old signature has been

    boolean isUpToDate(FileScanner[] scanners, File zipFile) 

and right now it is

    boolean isUpToDate(ResourceScanner[] scanners, FileSet[] fss, File zipFile)

ResourceScanner is an extension of FileScanner that we need to handle
ZipEntry-s and Files in a uniform way.  If we merged the additional
methods from ResourceScanner into FileScanner, things will get even
worse as we'd now not only break API compatibility for a protected
method, but for a complete interface (that is implemented and not yet
touched in the ftp task for example).

The FileSet argument is necessary as the scanners themselves don't
know about fullpath or prefix attributes that have to be taken into
account when checking the existing archive for up-to-date-ness.

I see no way to get around this.  We could invoke the old method from
the new one, but not the other way around, i.e. all subclasses
invoking the old method signature won't get what they think they'll
get.

Which leads me to think that we should go even further, drop the
ResourceScanner argument (they can be derived from the FileSets) and
even replace the method by one that returns the resources that are
newer than the archive instead of just saying the archive was out of
date.

This would then lead to changed signatures in the various addFiles
methods as well, but ultimately result in code that may be easier to
detangle.  Without changing the signature of the add methods, we'd
either have to perform the "which resources are newer" check twice or
cache the results in instance variables (and rely on subclasses to
delegate to our protected methods).

Quite a big change for a minor release.

To make things worse, 1.6 is going to break the API once again, this
time the zipFile and zipDir methods are problematic as they now have
additional arguments for the (Unix) permissions.  This time subclasses
trying to override Zip's methods get into problems.

So what are we going to do?

Break the API twice with the next two releases?  Delay the fix for 1.6
and break the API then?  Merge the new permissions stuff into 1.5.2
and break the API there?

Stefan

Mime
View raw message