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