Thanks Steve, I'll try it out when I get home. I am using 10.9.5 (Mavericks), not Yosemite. I'm using different entitlements under Danno's suggestion, and it has worked so far until some time in the last month.
On Mon, Nov 10, 2014 at 3:29 PM, Steve Hannah <st...@weblite.ca> wrote: > I was just reading through your original codesign script for your > infinikind bundler option, and I noticed that you are using different > entitlements for the libs than for your app. I don't recall if > entitlements are even required for the libs, but I have always just used > the same entitlements for my libs as for my app. The script that I use is: > https://gist.github.com/shannah/fb2d89592f627d67d162 > > I haven't tried building with Yosemite yet, so it may suffer from the same > problems as yours. > > Steve > > On Mon, Nov 10, 2014 at 11:46 AM, Danno Ferrin <danno.fer...@oracle.com> > wrote: > >> This may be a bug in 8u20. By setting -Bclasspath=<whatever> it should >> be putting <whatever> in as the string. I'de have to dig up the code >> because that section of code is uner a major overhaul for 8u40 because of >> the new launcher work. >> >> On Nov 10, 2014, at 10:33 AM, Zach Oakes <zsoa...@gmail.com> wrote: >> >> > I can see from the Info.plist file in the app bundle that >> JVMAppClasspath is an empty string: >> > >> > <key>JVMAppClasspath</key> >> > <string></string> >> > >> > On Mon, Nov 10, 2014 at 12:27 PM, Zach Oakes <zsoa...@gmail.com> wrote: >> > It looks like the classpath is always just the main jar, no matter >> whether I explicitly use -classPath or not. I am running >> System.getProperty("java.class.path") and it returns "/path/to/myapp.jar" >> and nothing else. This is the current command I'm running: >> > >> > javapackager -deploy -native \ >> > -name MyApp \ >> > -outdir out \ >> > -outfile MyApp \ >> > -srcdir bin \ >> > -appclass myapp.Main \ >> > -BappVersion=0.4.2 \ >> > -Bicon=logo_launcher.icns \ >> > -BmainJar=myapp.jar \ >> > -Bmac.category=public.app-category.developer-tools \ >> > -Bmac.CFBundleIdentifier=info.oakleaf.myapp \ >> > -Bmac.CFBundleName=MyApp \ >> > -Bmac.signing-key-app="3rd Party Mac Developer Application: XXXXX" \ >> > -Bmac.signing-key-pkg="3rd Party Mac Developer Installer: XXXXX" \ >> > -Bmac.app-store-entitlements=MyApp.entitlements >> > >> > On Mon, Nov 10, 2014 at 12:09 PM, Danno Ferrin <danno.fer...@oracle.com> >> wrote: >> > No, the class path is either set to all the files in the srcdir, or to >> whatever you explicitly set it to. Since you explicitly set the class path >> to -BclassPath=myapp.jar:ObjCBridge.jar:jna.jar then the class path is >> explicitly set. >> > >> > Note that with the javapackager everything passed in as a resource to >> -srcdir and/or -srcfiles is placed in .../Contents/Java, and nowhere else. >> This is so it works mostly the same with Windows and linux, where those are >> placed in .../app. >> > >> >> On Nov 10, 2014, at 10:06 AM, Zach Oakes <zsoa...@gmail.com> wrote: >> >> >> >> Oh, I didn't realize you could just put native libraries in srcdir. Is >> the classpath is set to .../Contents/Java as well? I have a few extra jar >> files my app needs to use. I can see they are copied there successfully, >> but I can't seem to find their classes on the classpath. >> >> >> >> On Mon, Nov 10, 2014 at 11:24 AM, Danno Ferrin < >> danno.fer...@oracle.com> wrote: >> >> Is this a verification on the part of apple? Is it that the program >> does not find the library? Or is it that the native library is not in the >> .app package at all? >> >> >> >> For 8u20, the launcher javapackager provides sets the >> java.library.path to be <app root>/Contents/Java, so a call to >> System.loadLibrary("jcocca") should be loading >> .../Contents/Java/libjcocca.dylib >> >> >> >> Is the native library in the -srcdir? >> >> >> >> >> >>> On Nov 10, 2014, at 8:59 AM, Zach Oakes <zsoa...@gmail.com> wrote: >> >>> >> >>> The error is the parameter dealing with the native library, >> libjcocoa.dylib, that my app requires. Does javapackager support adding >> native libraries? It should be copied into MyApp.app/Contents/MacOS. >> >>> >> >>> On Mon, Nov 10, 2014 at 10:41 AM, Zach Oakes <zsoa...@gmail.com> >> wrote: >> >>> Ah, forgive me, there was an error in the bundle process so it >> stopped short of creating a pkg. I will keep working on the parameters to >> see if I can fix it. >> >>> >> >>> On Mon, Nov 10, 2014 at 10:38 AM, Zach Oakes <zsoa...@gmail.com> >> wrote: >> >>> Definitely progress! It ended up creating a bundle, but not a pkg >> file. Maybe it's trying to make a normal mac bundle? I am using 8u25, by >> the way. >> >>> >> >>> On Mon, Nov 10, 2014 at 10:26 AM, Danno Ferrin < >> danno.fer...@oracle.com> wrote: >> >>> Try just '-native' and not '-native mac.appStore'. I think there >> were case checking issues in the 8u20 release. >> >>> >> >>> On Nov 10, 2014, at 8:25 AM, Zach Oakes <zsoa...@gmail.com> wrote: >> >>> >> >>>> Danno, since you mentioned javapackager, I decided to try using it >> in hopes that it would solve the issue. I'm trying to put together a >> command for it, but it's a bit confounding. So far I'm just getting a jnlp >> and html file to appear. Here's what I have so far (split onto separate >> lines for readability): >> >>>> >> >>>> javapackager -deploy >> >>>> -native mac.appStore >> >>>> -name MyApp >> >>>> -outdir out >> >>>> -outfile MyApp >> >>>> -srcdir bin >> >>>> -appclass myapp.Main >> >>>> -BappVersion=0.4.2 >> >>>> -Bicon=logo_launcher.icns >> >>>> -BclassPath=myapp.jar:ObjCBridge.jar:jna.jar >> >>>> -Bjava.library.path=libjcocoa.dylib >> >>>> -Bmac.category=public.app-category.developer-tools >> >>>> -Bmac.CFBundleIdentifier=info.oakleaf.myapp >> >>>> -Bmac.CFBundleName=MyApp >> >>>> -Bmac.signing-key-app="3rd Party Mac Developer Application: XXXXX" >> >>>> -Bmac.signing-key-pkg="3rd Party Mac Developer Installer: XXXXX" >> >>>> -Bmac.app-store-entitlements=MyApp.entitlements >> >>>> >> >>>> On Sun, Nov 9, 2014 at 7:13 PM, Danno Ferrin < >> danno.fer...@oracle.com> wrote: >> >>>> What are your entitlements? For javapackager we sign only the >> master package with real user supplied entitlements, every other jar, >> dylib, and executable gets an entitlement with an entitlements that is just >> sandbox and inherit. We also don't put entitlements on the JRE package >> when it is signed under plugins. >> >>>> >> >>>> >> >>>> On Nov 9, 2014, at 2:26 PM, Zach Oakes <zsoa...@gmail.com> wrote: >> >>>> >> >>>> > It looks like Apple has changed its codesigning requirements for >> the Mac >> >>>> > App Store. Thus far, I've been packaging my Java app using Oracle's >> >>>> > appbundler tool and signing it with the following script: >> >>>> > >> >>>> > http://pastebin.com/BtLV9bur >> >>>> > >> >>>> > This worked fine even as recently as last month. This time, I get >> an email >> >>>> > from them with the following: >> >>>> > >> >>>> > Invalid code signature - Signatures created with OS X version >> 10.8.5 or >> >>>> > earlier [v1 signatures] are obsoleted and will no longer be >> recognized by >> >>>> > Gatekeeper beginning with OS X version 10.9.5. To ensure your apps >> will run >> >>>> > on updated versions of OS X they must be signed on OS X version >> 10.9 or >> >>>> > later [v2 signatures]. For more information, see OS X Code Signing >> In Depth >> >>>> > >> >>>> > I think this error is incorrect, because I'm using 10.9.5 with the >> latest >> >>>> > Xcode (6.1). I tried "codesign -dv MyApp.app" and it says "Sealed >> Resources >> >>>> > version=2 rules=12 files=7", so I think I am using v2 signatures. >> My JDK >> >>>> > version has not changed since last month (8u25), so I can rule >> that out. >> >>>> > >> >>>> > I would appreciate any help. Thank you. >> >>>> > >> >>>> > Zach >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> >> >> >> >> >> > >> > >> > >> >> > > > -- > Steve Hannah > Web Lite Solutions Corp. >
