Getdown is currently failing to create patch files because JarDiff is closing the outputstream. The attached patch comments it out, which seems to work.
moderately more sane progress indication.
It's still non-ideal, because, for example, we'll start out assuming everything
is length 1. So we'd have a queue like (1, 1, 1, 1). Then we start downloading
the first resource and see that we actually have (1500000, 1, 1, 1), so we
climb up to 99% downloading that first resource, and then we find out that we
have (1500000, 450000, 1, 1) and we pop back down to 70% or so, and so on as we
discover in turn that the web server lied to us about each file.
The alternative is to just sit at 25% for ages, then sit at 50% for ages, then
75%, etc. Maybe that's better... I guess I just like to see some sort of smooth
upward progress.
This is only a problem for me since I'm hosting a Getdown client on Github
which lies about Content-size in a HEAD request. So OOO projects will continue
to give accurate progress reports.
individually. Cap the actual download size at the reported size to ensure that
we don't end up borking our progress calculations if a web server returns a
"clever" value for content-size like 1 or 0, but then sends back real data.
Also sanitize the returned content-size in case the web server says something
awesome like -42. No one can be trusted on the Interwebs, least of all web
servers.
annoying dependency on javaws.jar (which no longer even includes JarDiff, now
that lives in $JAVA_HOME/samples/jnlp/servlet/jardiff.jar). We had already
forked JarDiffPatcher, so this completes the circle. Now I can also directly
fix some of the annoying JarDiff bugs we were working around, which I'll do at
some point.
os.name. If no architecture is specified, all architectures match, which
preserves the existing behavior.
Restructured things along the way to be more amenable to unit testing, and
added some unit tests.
Dave Hoover