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