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.
