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.
clobbering version of getdown from r274, and that environment clobbering seems to prevent launching
on Linux and some Windows installs. Now if we want to release with the fixed version of environment
setting and an environment.txt, the clobbering version will run as part of the update, process the
newly downloaded environment.txt, and never launch again. By renaming it env.txt, we can skirt
around that whole fiasco and environment setting won't go into effect until the new getdown is
running.
Michael Bayne