Ulrich Kortenkamp wrote:
>We definitely don't want Java Web Start to pull the latest version of our
>servers, but we want that users who download a .dmg or get it on CD can
>run the application like they can with any other application.
>
>Or did I miss a way to make JWS work locally? (without running a web
>server an connecting to localhost)
The Info.plist in an app-bundle created by JWS contains a file: URL instead
of the usual Java dictionary and other key/value pairs. I forget the exact
key/value being used, but you can find out by running any JWS app and
telling JWS to create a local app on the HD for it. Then look inside the
resulting app-bundle's Info.plist. I think even double-clicking a local
.jnlp file will launch JWS.
In the usual JWS case, the URL points into the JWS cache. In your case, I
don't think there's any reason it can't point to a file or files located
within the app-bundle itself. The goal is to make the app-bundle
completely self-sufficient, not relying on the vagaries of JWS's cache, yet
still ride on the back of JWS's local-app bundling syntax.
I have not tested this, but it seems straightforward to try it. I believe
you'll need a local JNLP file as the primary resource that the Info.plist
URL points to. After that, I'm not sure what the JNLP file itself should
contain. I suspect that file: URL's will be needed instead of http: ones.
If a file: URL has to be absolute, that will prevent the bundled app from
being moved, so if your users might do that, a defense may be in order.
For example, an absolute URL that points somewhere immovable, like into
/Library/Application Support/YourAppName/ that holds your app's actual JNLP
and jar files, leaving the app-bundle itself a mere husk.
One possible down side: I'm not sure if file-bindings to the app would
work. I haven't tried that, either.
If that strategy doesn't work out, a shell-file is possible. However, it
need only make the i386/ppc decision once, the first time it's run on a
platform. At that point, it can write something or change something (such
as its own executable or its Info.plist) so that future launches go
straight to whatever the result of the first decision was. Kind of a
self-installing app.
It should else detect when it's running on read-only media (e.g. a
compressed disk-image), and not fail if it can't write its decision. It
would then have to make the decision at each launch. C'est la vie.
The 'arch' command prints the architecture, so that's easy to get in a
shell script. I just checked, and the 'arch' command exists as far back as
10.0, so it's safe for all Mac OS X targets.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
