Re: What do we need to change to sign java appbundle since updating from 10.9.4 to 10.9.5
On 18/09/2014 20:22, Hendrik Schreiber wrote: 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 Ive raised this issue on AppBundler https://bitbucket.org/infinitekind/appbundler/issue/1/appbundle-built-on-mac-osx-1095-cannot-be Paul
What do we need to change to sign java appbundle since updating from 10.9.4 to 10.9.5
Can somebody help me with this please I just updated from OSX 10.9.4 to 10.9.5, and it looks like I have to change how I sign Java application after updating because Im now getting this output after signing with export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate /usr/bin/codesign --sign Developer ID Application: P Taylor --force --deep --verbose /Applications/SongKong.app Im getting: /Applications/SongKong.app: the main executable or Info.plist must be a regular file (no symlinks, etc.) In subcomponent: /Applications/SongKong.app/Contents/PlugIns/jdk1.8.0_20.jdk and verification with /usr/bin/codesign --verify --deep --verbose /Applications/SongKong.app gives me /Applications/SongKong.app: code object is not signed at all In architecture: x86_64 What do I have to change to fix this ? Paul
Re: What do we need to change to sign java appbundle since updating from 10.9.4 to 10.9.5
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. On Sep 18, 2014, at 10:19 AM, Paul Taylor paul_t...@fastmail.fm wrote: Can somebody help me with this please I just updated from OSX 10.9.4 to 10.9.5, and it looks like I have to change how I sign Java application after updating because Im now getting this output after signing with export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate /usr/bin/codesign --sign Developer ID Application: P Taylor --force --deep --verbose /Applications/SongKong.app Im getting: /Applications/SongKong.app: the main executable or Info.plist must be a regular file (no symlinks, etc.) In subcomponent: /Applications/SongKong.app/Contents/PlugIns/jdk1.8.0_20.jdk and verification with /usr/bin/codesign --verify --deep --verbose /Applications/SongKong.app gives me /Applications/SongKong.app: code object is not signed at all In architecture: x86_64 What do I have to change to fix this ? Paul
Re: What do we need to change to sign java appbundle since updating from 10.9.4 to 10.9.5
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
