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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >> >> >