which was used by Maven, now Maven calls into the primary build to generate its
Proguarded jar file. Retired the Retroweaved jar file after a tremendous amount
of fucking around with Retroweaver. I think it's safe to say that the number of
people showing up with a 1.4 JDK operational in their browser is epsilon close
to zero.
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.
message.
We want to put everything into one jar file which we'll publish via Maven. So
we include our command line tools, and replace the un-proguarded jar with the
proguarded one during the packaging step.
I may look into not renaming the Getdown code so that apps (like Bang) that
link against some of it, can use this jar file. Or I'll just figure out
specifically what apps are likely to link against and not rename just that.
It's probably not a huge size increase either way.
hair-pulling and ball-ache. We now have Maven call out to an Ivy-based Ant task
to do the Proguard build (with Ivy maintaining a parallel copy of the
dependencies, unfortunately). It's a twisty maze of passages, but it gets the
Proguard build done during the right Maven phase so that all of its magical
building, version number changing, SVN commits, etc. can happen as usual during
the publishing process.
to build and publish Getdown. Everything builds with Maven, but getting
Proguard to work inside Maven is an exercise in gouge-my-eyes-out-now, so I'll
be doing the Proguard bits in a separate Ant script which will use Ivy to
obtain dependencies sanely. This too is rife with PITA, but less so than doing
everything in Maven. Ivy bits don't yet work.
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.
much smaller than the background image. If we're going to change the
preferred size of the StatusPanel, we have to invalidate it so that
Window.pack knows to recompute the bounds. The reason this worked sometimes
(or even most of the time) is that there's a race condition between the
Getdown thread and the AWT thread: sometimes the real interface bits (_ifc)
are in place by the time initInterface is first called, sometimes not. For
the sake of consistency, we should probably fix that, but for now it's not
a big deal: the backgroundless interface is rarely visible.
Michael Bayne