Darn. Is there no way to manually insert values into the Info.plist before
it is signed? If not, I guess I'll keep trying to get my custom script to
work. I just need some kind of short term solution to get this app update
out...
By the way, I noticed there is also no way to set the CFBundleVersion, so
it's always set to 100. That would prevent me from using the tool as well.
Note that I am using 8u25, not 8u20.
Zach
On Mon, Nov 10, 2014 at 2:46 PM, 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
