Re: MAS codesign requirements break Java app signing
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: keyJVMAppClasspath/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: X \ -Bmac.signing-key-pkg=3rd Party Mac Developer Installer: X \ -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: X -Bmac.signing-key-pkg=3rd Party Mac Developer Installer:
Re: MAS codesign requirements break Java app signing
Thanks Steve, I'll try it out when I get home. I am using 10.9.5 (Mavericks), not Yosemite. I'm using different entitlements under Danno's suggestion, and it has worked so far until some time in the last month. On Mon, Nov 10, 2014 at 3:29 PM, Steve Hannah st...@weblite.ca wrote: I was just reading through your original codesign script for your infinikind bundler option, and I noticed that you are using different entitlements for the libs than for your app. I don't recall if entitlements are even required for the libs, but I have always just used the same entitlements for my libs as for my app. The script that I use is: https://gist.github.com/shannah/fb2d89592f627d67d162 I haven't tried building with Yosemite yet, so it may suffer from the same problems as yours. Steve On Mon, Nov 10, 2014 at 11:46 AM, 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: keyJVMAppClasspath/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: X \ -Bmac.signing-key-pkg=3rd Party Mac Developer Installer: X \ -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
Re: MAS codesign requirements break Java app signing
With the Ant task, I already can manually edit my Info.plist so that's not an issue. The problem with it is simply that Apple is rejecting it after I upload the app with the error message I included in the OP. There is something wrong with the sig but I can't figure out what it is. On Mon, Nov 10, 2014 at 4:28 PM, Alan Snyder javali...@cbfiddle.com wrote: If you are using the Ant task, you may be able to get Ant to look for the resources using the classpath specified in the taskdef. However, that works only if the ant task JAR is not on Ant's classpath. It took me a while to figure that out. On Nov 10, 2014, at 1: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.
Re: MAS codesign requirements break Java app signing
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... keyJVMAppClasspath/key stringObjCBridge.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: keyJVMAppClasspath/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: X \ -Bmac.signing-key-pkg=3rd Party Mac Developer Installer: X \ -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
