This means that the automatic JNLP file creator lists the incorrect JAR as the first JAR causing it to fail finding the main class and thus the game cannot load.
Specifying the main-class using the form field belwo the jar list is supposed
to make this unnecessary (according to the webstart docs). That was the way Sun chose to implement it
- are you saying the main-class field/tag isn't working?
EDIT: if you're merely saying you don't want the hassle of doing this
then I'm right with you...
- add a radio check box for each JAR to nominate the Jar that should be first in the list when generating the JNLP file
or allow game owners to edit the generated JNLP file
That's not a trivial change (basic SQL is poor at supporting easy custom sorts), so it's not especially likely to happen unless there's something wrong with the main-class system, or I find myself messing with that page (SQL filter + back-end processing code) for some other reason.
Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.
- Each time a version is created, users have to re-download every JAR, even if those JARs are unmodified.... so can you store the JARs on the sever in such a way as to not change the url for the jars each time a version is created, rather only change it when it is updated?
Yes, this is a nasty bug that was introduced a while back - and is one I've been wanting to get rid of personally for some time. It's a side-effect of two things:
1. when an author changes the version, we have to keep the files independent of old copies, in case of new inadvertent bugs; versioning by directory was a very simple way of achieving this that needed no code changes at the time (and see below for why this was done, even knowing it screws up the timestamp / basic webstart protocol)
2. Sun's basic download protocol sucks in many ways, and this is one of them: it has no way for you to tell it that its copy of file X is actually now named file Y (IIRC redirects cause it to break - but don't take my word for it, and I ought to double-check); IIRC (off the top of my head) you can't even change the codebase to have this effect, and/or changing the codebase doesn't work because you aren't allowed to use ".." syntax - one or the other, which is intensely annoying (and pretty stupid / shortsighted).
The intended solution was to switch to using the "other" protocol that is built-in to webstart: the "version protocol". Rather than encode the version in the filename, this protocol has an extra attribute in the JNLP file (version="", unsuprisingly
) and allows the server to return whatever file it wants, including jardiffs and other exciting stuff.
However, I just heard from Mark Thornton that java 1.5 breaks the version protocol - things like webstart CD installs won't work with the version protocol.
So ... this needs more thought
. Rest assured, I'm working on it, but with webstart on the server you often find that every avenue you try doesn't work because of different bugs or stupidities in Sun's webstart spec or client implementaiton. So, you have to keep on thinking up new workarounds, and testing them, in the desperate hope of finding the one that works
Thanks for the comments; if nothing else, they help with deciding what to prioritise next