On Sep 18, 2014, at 20:49, Paul Taylor <paul_t...@fastmail.fm> wrote:
> 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 ? Perhaps AppBundler should simply not copy the MacOS folder. I don't see how it's needed when bundle the JRE as plugin and launch with the AppBundler stub. -hendrik
