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