On 18/09/2014 18:16, Danno Ferrin wrote:
On the javapacakger (javafxpackager) side of the house we dodge this by not
using the symlinked JLI.
The JDK as it is installed installs a symlink to the libjli.dylib in
...app/Contents/MacOS is actually a symlink. I don't know if you copy it if it
will still work, it may want to live in
...app/Contents/Home/jre/lib/jli/libjli.dylib. This is referenced in the
default info.plist
The way we dodge this for the javapackager is we create our own launch native
that opens up the libjli from the location deep in the JRE. And we don't ship
the symlink.
I can confirm that javapackager 8u20 signs and launchers with 10.9.5, but I
haven't tried to submit it to the app store since the signing requirements
changes.
So I don't know how you launch, but the info.plist cannot refer to the
symlinked libjli.dylib if it is symlinked, and it may not even be allowed to
exist as a symlink in ...app/Contents/MacOS. So if you can remove the symlink
before signing that may help.
Im using a fork of Java Application Bundler from InfiniteKind -
https://bitbucket.org/infinitekind/appbundler -Im not deploying to the
appstore its just uploaded to my website.
So following your advice I found that libjli.dylib in
Contents/PlugsIns/jdk1.8.0_20.jdk/Contents/MacOS pointed to
../Home/jre/lib/jli - replacing the symbolic link with a copy of the
file has allowed the signing to work, and when installed the application
stills seem to work, thankyou :)
'
I assume if it doesn't work then you'll have a problem with
javafxpackager applications as well.
Any thoughts from dev team about removing this symbolic link in the jdk ?
Paul
