page hosting the applet and the launched application through a simple server
socket bound to the loopback address on any available port (where the port
is passed to the application as a system property). Not tested yet, but it
shouldn't affect any deployments that don't specifically enable it.
of using the signers on the jar file. Also tidied up the code that passes
certificates around so that we get rid of that wonderful Object[] as early as
possible.
getdown-pro.jar and it's only 10% larger (109k -> 121k), and it vastly
simplifies life for users.
Just use getdown-pro.jar for all of your Getdown-related needs:
- use it to install your application
- use it in your build scripts for the various Getdown tasks
- link against it in your app to use LaunchUtil or to embed Getdown
We'll even ship this on the website as simply getdown.jar. I'm tempted to ship
this in Maven and modify the main Getdown POM to not export any of its
dependencies. However, that will require a bunch of build file tweaking, which
I'd rather save for another day.
of inconsistent-with-one-another-and-with-getdown.txt-and-limitation-ridden
'properties' and 'app_properties' mechanisms from ancient history.
Unfortunately, Sun in their infinite wisdom decided that being able to
enumerate applet parameters was "not doing it right" and provided no mechanism
for doing so. So we have to use annoying increasing int suffixes.
Use like so:
<object ..>
<param name="jvmarg0" value="-Xmx256M"/>
<param name="jvmarg1" value="-Danswer=42"/>
<param name="jvmarg2" value="-Dtrix=for kids"/>
<param name="jvmarg3" value="-Dfoodir=%APPDIR%"/>
<param name="apparg0" value="--username"/>
<param name="apparg1" value="elvis"/>
</object>
complain if you actually provide an unparseable rect or color. If you don't
provide one at all, we'll use the default.
I want people to be able to configure Getdown with just:
ui.name = My Project
and get a no-frills, but usable interface that displays download and
installation progress. Previously, this resulted in a bunch of warnings when
they tried to generate their digest.txt because they failed to supply cryptic
things like "ui.progress = 17, 321, 458, 22". I'd rather that be optional.
I may add some sort of "spurious config" warning, so that if you provide
"ui.progres = 17, 321, 458, 22" and you're wondering why things aren't working,
you don't spend hours pulling your hair out.
When I'm feeling more up to it, I'll potentially rejigger this to
allow its use if it's available, but for now just simplify it so
folks can set a single icon.
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.
Andrzej Kapolka