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