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

Reply via email to