I successfully am replacing the Info.plist file with the technique you
mentioned. Is it possible that the JVMAppClasspath key does not actually do
anything? I added the extra jars to it, trying both a space and a colon as
a separator, and the java.class.path is always just the main jar file.
Sorry for the continuous problems...
<key>JVMAppClasspath</key>
<string>ObjCBridge.jar jna.jar</string>
On Mon, Nov 10, 2014 at 4:10 PM, Danno Ferrin <danno.fer...@oracle.com>
wrote:
> You can insert values into the Info,plist, it just involves some
> acrobatics. There is a resource replacement technique that looks for the
> resource on the classpath of the execution of the tool, which for the CLI
> includes the current directory. There are also some peculiarities for the
> name. For the Info.plist it would be loaded from
> ./package/macosx/Info.plist.
>
> If you use the -verbose or -v option the javapackager tool will both leave
> the default files in a temporary directory (that it will tell you about)
> and tell you specifically where to put replacement files.
>
>
>
> On Nov 10, 2014, at 1:41 PM, Zach Oakes <zsoa...@gmail.com> wrote:
>
> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
