Paul Archibald wrote:
>We are thinking about the installer for our app, and my partner is thinking
>of a universal installer of some sort for Windows and Mac. I don't see his
>reasoning, but I want to check a couple of things with you folks before I
>say "that is a lousy idea"! )I want to use PackageMaker.)
Exactly what does your installer have to install? Sometimes even
PackageMaker is a lousy idea. If you just have the app, and not any
supplementary files scattered around, you could skip the installer entirely.
<http://developer.apple.com/documentation/Java/Conceptual/Java14Development/03-J
avaDeployment/JavaDeployment.html>
A dmg download with the app on it, ready to run, avoids having to shepherd
the user through an install. Because everything a user has to install
before trying, a user also has to de-install if they decide it sucks. If
your app is on a dmg, and it runs from there, then users can try the app
without an install, and then simply drag it where they want it to be.
Even if your app DOES need some files installed, it can be adaptive,
installing the files it needs if it doesn't see them already present. This
also makes the app more robust, as it can self-recover if some files become
unavailable for some reason. This approach isn't always possible, but it's
very nice if it can be done.
For an app that requires Java 5, I have deployed apps which first confirm a
suitable Java version. This "confirmer" layer is compiled for only JDK
1.3, and so will run on anything that Apple ever shipped on Mac OS X. If
the correct JVM is present, it then loads the rest of the app using
Class.forName(), and that code then targets 1.5. If the JVM is not 1.5,
then the confirmer presents an alert with corrective actions, and then
exits. I once set it up so the alert had a button that called the 'open'
command on a URL for Apple's Java 5 download. That worked nicely, too.
It's not difficult to write the confirmer with Xcode. You just add a Java
target, set it for 1.3, and then add a composite target that produces a
single merged jar from the confirmer and the real app. A confirmer-lib
project is also a good way to go, because the confirmer itself need not be
tied to a particular Java app: it's reusable.
>1 The app requires Java 5. If our users need to upgrade their Java, it
>looks like the best way to handle that is by pointing them at Apple's
>website for a new version. That means an 80Mb download, but I don't see any
>reasonable alternative. Is there another way of getting a Java upgrade that
>I have missed, one which is not so big?
Nope.
>(I am against bundling the latest Java with our app, that sends our package
>size from around 6Mb to 86Mb, which my poor 28k dialup can't handle.)
Apple's license does not permit redistribution with your app.
>2. Can PackageMaker be set up to check the Java version, and maybe
>download it? (or is this question not for this forum?)
Check Java version: yes.
Maybe download it: no (or not easily).
Not for this forum: correct, try:
<http://lists.apple.com/mailman/listinfo/installer-dev>
-- 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
