Thus spake Flint1b:
Oh my, I didn’t realize that deployment is such a problem on desktops.
Server-side Java and deskop Java are quite far apart. It’s like being
in a building which is so large that you can be happily working at one
end while the other end is on fire.
I
assume it’s not an option to just deliver a jar and a shell script or
.bat file that runs it with the proper parameters, and tell the users to
have a JRE installed, unzip the package and run the script?
The reason we put together a Windows installer in the first place was to
head off all the problems users had with getting set up. The reason we
had the installer check if Java was installed and download and install it
if now was to head off all the problems users had with getting set up.
The reason we’re bundling Java with 3.3 is—wait for it—to head off
all the problems users had with getting set up.
It is hard to convey the diversity and quanitiy of installation issues
I’ve seen users have. I would never have beleived it had I not seen it
happen myself. Minimizing the ways that things can be screwed up will
always pay us back in time and reputation, so it’s worth it.
No
installers, just like in the linux package? This is the only way I would
want to run a Java application and I even had to mess with the shell
script to get 3.2 to run on my linux, but I assume I am a very special
kind of user in that respect. And doesn’t a jar file run when
double-clicked, so the shell script or .bat file could be even dropped
to not confuse the users?
A JAR won’t run when double-clicked if you don’t have Java installed,
or if you don’t have Java installed correctly. Of course, that would
not be our fault, but we nonetheless get blamed for it when it happens.
I would be interested to know how you had to modify the shell script,
as my intent was that no one would need to do that.
And the jpackage, I see now that it needs to run on the target platform
in order to package for that platform, I don’t have access to a Windows
or Mac but surely some of the developers have a Windows and a Mac and
could do the packaging? Or how is Vassal and its deployment on Win/Mac
tested by the developers? Also there is some extra code for a Mac
(ugh… in a platform-independent language), how is this tested if
none of the developers have access to a Mac?
I have both Windows and Mac VMs here. I test things in them. I have zero
interest in firing them up just to build a package. That’s a massive waste
of time. I sometimes build a package a dozen time in an evening. I must be
able to produce a package in the environment in which I’m developing.
I hate to tell you, but Java’s never been platform-independent on the
desktop, both because different JDKs have have different bugs and because
desktop envionments just differ in ways that are hard to paper over.
–
J.