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