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.
Dave Hoover