What did you do to make the ‘-auto’ (and related bits) work? This was
my sticking-point earlier today with trying to build a bundle. (I’m
trying to have a look at your file, but it’s going to be another hour
downloading - are you hosting it on dial-up? grin)
I do still like the app bundle approach, but I do understand it’s a
manual (or needs-scripting) step for Tim M each time the module changes.
Just been playing a bit more with the ‘cc.command’ approach - it’s
possible, by passing ‘-Dapple.laf.useScreenMenuBar=true
-Xdock:name=“CombatCommander”’ to the java invocation to get things bit
more Mac-like, although the ‘About’ box still contains garbage.
Allegedly we could pass an icon file in that way too, just by having one
somewhere in the module zip file, but I haven’t tried that. Also, this
approach leaves a ‘dead’ Terminal window hanging around afterwards,
which isn’t exactly great user experience.
What was the third option? Giving people instructions on running cc.sh
through Terminal?
On Jan 28, 2008, at 11:08 AM, Timothy Mccarron wrote:
No. Just renaming the shell file works fine.
It will then launch the Mac Terminal (Unix window) and run the script.
I think that the most convenient, and most Mac-like solution is to
build (package) a Mac .app file. The shell file is just a quick and
easy work-around that is perhaps a bit too Unix-like for non-
programmers on the Mac.
Build the application and distributing it as a .dmg file would be the
best from the user perspective.
I’m no techy but I was wondering why the CC mod needs a different approach to get it up & running from all the other mods posted on vassal? Usually u dl and either unstuff or leave stuffed and away ya go!
I have no clue whether this will work at all. In addition, it might behave
oddly, look strange, violate cultural taboos for Mac users, or eat your
children. I don’t know, because I can’t test it myself. I need your comments.
Also, I built this by hand the first time, because I simply can’t get the
JarBuilder Ant task to work. (That’s ok, since I’m no fan of Ant, and I’ve
already made a target in my Makefile for this.)
Oh, I see - didn’t realise you could put a shell script into a bundle
where it’s expecting an executable. Neat trick
However:
Dock icon is generic Java one, not the application one
About dialog is nonsense
Menu bar is in window, not Mac menu bar
Application menu title is org.vassal.Main, not VASSAL or Combat Commander
The latter two I know we can fix by tweaking the script. I’m not sure
if the first two can be fixed in Info.plist - I’m open to suggestions.
I know they can be fixed that way with a Jar Bundler app that uses
JavaApplicationStub instead of the script, but then I can’t see how to
make ‘-auto’ work…
Java version needs to be ‘1.5+’, not ‘5+’, or it won’t start at all.
I suspect it’s going to need every JAR in the Resources/Java dir adding
to the Classpath array.
I also suspect the MainClass wants to be VASSAL.launch.Main, not
VASSAL.launch.Launcher (it is for my bundle, but I don’t know what
changed from there (3.0.15 release) to SVN-2911.
However, I can’t check the latter two, as I get this trying to start it,
with or without those changes:
tim@feathers:~/Download/VASSAL-3.1.0-svn2911.app/Contents/MacOS$
./JavaApplicationStub
[LaunchRunner Error] VASSAL.launch.Main.main(String) threw an exception:
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at VASSAL.launch.Main.initSystemProperties(Main.java:124)
at VASSAL.launch.Main.(Main.java:54)
at VASSAL.launch.Main.main(Main.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at apple.launcher.LaunchRunner.run(LaunchRunner.java:88)
at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)
at
apple.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:52)
Class versioning errors and actual mechanics of class loading is getting way beyond my Java skills, so I hope it means something more to you…
Bedtime now, if there’s any more specific things I can try / collect,
let me know.
================================================================
Could not launch the application because it requires a version of
Java that is not installed.
The application requires Java 5 or later, but only the following
java versions are installed: 1.5.0, 1.4.2, 1.5, 1.4. Updating to a
newer version of Mac OS X may resolve this.
Of course, I’m running the latest version of Mac OS X.
Changing that to be correct got a bit further, but still ran into an
error with the class file version. Did you perhaps compile this under
Java 1.6? That is not available on the Mac, and Apple hasn’t said
anything at all about plans for Java 6. (Grumble).
[LaunchRunner Error] VASSAL.launch.Launcher.main(String) threw an
exception:
java.lang.UnsupportedClassVersionError: Bad version number in .class
file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
at VASSAL.preferences.Prefs.getGlobalPrefs(Prefs.java:185)
at VASSAL.launch.Launcher.main(Launcher.java:46)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
39)
at
sun
.reflect
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:
25)
at java.lang.reflect.Method.invoke(Method.java:585)
at apple.launcher.LaunchRunner.run(LaunchRunner.java:115)
at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)
at
apple
.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:
52)
Heres Option 3 - the Info.plist version zipped up that the guy sent me. Ive deleted the actual mod (to upload) but left the folder structure so you would see where the jars go.
Joel, this may? be useful to you for the Vassal version to look at. Seems like you are both working on the same idea as this is based on your alls’ last few posts
Why? VASSAL.launch.Launcher doesn’t need any JARs except Vengine.jar.
Explanation below.
Launcher is a tiny class which reads the user’s preferences to get
the initial and maximum heap sizes for VASSAL and then launches
another JVM to run VASSAL with those settings. The point of this is
to make it possible to adjust the heap sizes from within the prefs
in VASSAL (though changes to these values can’t take effect until
the next time you start VASSAL—that’s unavoidable).
This is a feature which will be new in 3.1.0.
I compiled some classes with the 1.5 compiler earlier today—I might
have ended up with a mix as a result.
Yes, it was compiled with Java 1.6, but with the ‘-source 1.5’ option,
which the man page claims will produce 1.5-compatible class files
when ‘-target’ is left unset. (But there might have been another
probem, see my reply to Tim.)
It is normally the way applications are distributed, but it is only
really useful if what you are distributing has multiple files/folders
or runs an installer. If the application itself is all there is, you
could just forgo the step of producing a dmg file and just have the
users
move the application from their download area to the applications folder
or somewhere else.
[Of course, I recall reading about a user study done, IIRC by Apple,
which indicated that the instruction “drag AAA to BBB” was too
complicated for some users to follow, so they needed to have
installers…]
Bottom line: I don’t think it is necessary, but perhaps other
Mac users should chime in. I’m a professional computer scientist,
so my idea of what is easy is not at all representative of normal
people’s.
Still problems.
It crashes on launch with a class version error, but in a slightly
different place now.
(Oddly, my previous crash and Tim Franklin’s were in different places):
[JavaAppLauncher Error] CallStaticVoidMethod() threw an exception
Exception
in thread “main”
java.lang.UnsupportedClassVersionError: Bad version number in .class
file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at apple.launcher.LaunchRunner.loadMainMethod(LaunchRunner.java:55)
at apple.launcher.LaunchRunner.run(LaunchRunner.java:111)
at apple.launcher.LaunchRunner.callMain(LaunchRunner.java:50)
at
apple
.launcher.JavaApplicationLauncher.launch(JavaApplicationLauncher.java:
52)
On Mon, January 28, 2008 11:50 pm, Thomas Russ wrote:
Except you can’t do that, because the web / ftp site you’re serving from
won’t know to handle the Foo.app directory tree in the special Mac
‘treat-it-as-a-file’ fashion, and will treat it like any other directory.
So you either have to try and get the user to download a directory
structure (not too bad with a real FTP client, hard with a web browser, as
far I can make out), or you end up needing Foo.app.{zip,tgz} on the
download server.
Zip/tgz is easy to generate by script on non-Mac machines; if Joel’s found
a way to generate DMGs as easily, I’m all for it.
