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