To all that responded:
It was INDEED a permissions problem. When jar is used to archive files, it changes the permission on the JavaApplicationStubs from -r-xr-xr-x to -rw-r--r--, whereas tar preserves them. This won't show up on the Linux or Windows ports of our programs because they (obviously) don't have an OS X generated JavaApplication stub. For Linux, our configuration program is launched as a jar, which then sets up a desktop icon and configuration and then changes the permissions on the associated launch script. For Windows we use launch4j which creates a native Windows EXE file for those not familiar with it (launch4j is, as far as I'm concerned, a 5 star product for anyone that's ever needed to run Java apps under Windows as an EXE file with an icon, etc) Oddly, many of the permissions of the contents of the kit on OS X were not altered, but this might be because the kit was built using system default permissions.
Anyone writing code to store a kit in jar format and then make the jar a self extracting executable will likely need to put some code on the tail end of the program (after the jar is extracted) to go in and make permissions changes as needed. It's also a good idea to add code to delete the META-INF directory that gets dumped as well, IMHO.
THANKS AGAIN!!! :-)
From: Greg Guerin <email@hidden>
Date: 2007/03/31 Sat PM 09:20:06 CDT
To: email@hidden
Subject: Re: A broken jar?
bsd5tu1 wrote:
>This appears to me to be an OS X ONLY problem as I cannot replicate it on
>Windows or Linux, but then again neither of those versions of our product
>are in the ".app" format.
My first thought was as Mike Hall posted: file permissions. A jar file is
a zip file, and zip doesn't preserve permissions, where tar does. Refer to
the respective file-format specs.
I'm pretty sure that if you jar something up on XP and unjar it on Linux or
Mac OS X, there is NO WAY it will be executable unless you do some
post-processing, such as apply the 'chmod' command to the executable in
Your.app/Contents/MacOS/. AFAIK, the same is true if you jar it up on
Linux or Mac OS X, and then unjar it on Mac OS X or Linux. The plain ZIP
format simply doesn't preserve permissions, and 'execute' isn't applied by
default, so executables will simply not be executable straight out of a jar.
Other than the executable needing executable permission, there's nothing
special about the ".app" bundle format (assuming you don't have resource
forks). In other words, if you jarred the /bin/ls command on one Mac,
unjarred it on another, it would NOT be executable straight out of the jar.
This is due to the loss of the executable permission, and has nothing to do
with .app bundles.
Except for the executable permission, a typical .app should survive jarring
and unjarring. Executable permission is crucial, though, and without it
the unjarred result will NOT be directly executable.
On second thought, though, I'm not sure permissions is the problem. Linux
is Unixy enough that it has execute permission bits, so if your
self-extracting jar works on Linux, one would expect it to work on Mac OS
X, too. That really has me puzzled.
But then again, there isn't enough detail about exactly what goes into the
self-extracting jar, nor what comes out of it, nor what post-processing
might be done, nor what you did when you tested it on Linux, to really know
what's going on. I'm afraid you'll have to be more specific about exactly
what it's doing.
If I were trying to figure this out, I'd be checking two things:
1) file contents.
2) file metadata.
The first includes data-forks, and resource-forks, if there are any. The
second includes permissions, ownership, and possibly the classical
file-type and creator ID's. Any or all of these being "lost in transit"
can break an executable.
To check file contents, use the 'md5' command (see 'man md5') on the
original and on the extracted tree. They should be identical. Anything
with non-identical hashes has been corrupted.
To check resource-forks, append "/rsrc" to a file's pathname. For example,
a file "Foo.txt" has a resource-fork of "Foo.txt/rsrc". You can use this
notation in Terminal command-lines, shell-scripts, etc. The unadorned
target must be an ordinary file; directories can't have resource forks.
For illustration, make an alias of "Foo.txt" using Finder, then enter this
in Terminal:
ls -l "Foo.txt alias" "Foo.txt alias"/rsrc
The alias's data-fork will be 0 length, and its resource fork will be
non-zero length.
Checking metadata is harder, but you can use 'ls -lR' to get the
permissions, owner, group, etc. into a text form. If you do this on both
the original and extracted tree, sending stdout to two files, then you can
use FileMerge.app (in /Developer/Utilities/) to compare the files for
differences. You may find inconsequential differences, like mod-date, but
you should find no significant differences, like permissions, between the
two.
Be systematic and methodical, be sure you understand what each platform
requires (e.g. executable bits on Linux and Mac OS X; proper suffix on
Windows), and eliminate everything that jars and unjars or tars and untars
identically. Whatever remains is a likely cause of the problem.
-- 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
_______________________________________________
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
