Jessica, thank you so much. Your fix worked for me, and I wouldn't have
discovered it on my own. I'll try javapackager again when the next JDK
update comes, but this will certainly work for the time being. Thank you to
Danno, Michael, and the others as well for all the responses.
Zach
On Tue, Nov
Zach,
Having mentioned this on the side, I’ll say it again for posterity: I bundle my
app also using the appbundler and also have just recently been receiving that
same email from Apple upon app submission.
Today, I finally got my app bundle to be accepted (for the first part of the
process an
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
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,
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 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. F
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 wrote:
> I was just reading through you
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 CFBundleVersio
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
This may be a bug in 8u20. By setting -Bclasspath= it should be
putting 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 wrote:
> I can see from the Info.
I can see from the Info.plist file in the app bundle that JVMAppClasspath
is an empty string:
JVMAppClasspath
On Mon, Nov 10, 2014 at 12:27 PM, Zach Oakes wrote:
> It looks like the classpath is always just the main jar, no matter whether
> I explicitly use -classPath or not. I am running
> Sy
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 MyAp
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
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 res
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
/Contents/Java, so a call to System.loadLibrary(“jcoc
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 wrote:
> Ah, forgive me, there was an error in the
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 wrote:
> Definitely progress! It ended up creating a bundle, but not a pkg file.
> Maybe it's
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
wrote:
> Try just '-native' and not '-native mac.appStore'. I think there were
> case checking issue
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 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 toget
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
readab
I made the changes you described and I received the same error from Apple.
Below is the modified script I used. If you can see any other differences,
please let me know. It's frustrating since the error Apple gives is
seemingly irrelevant.
http://pastebin.com/JD2XY7YE
On Sun, Nov 9, 2014 at 7:24
On Nov 9, 2014, at 6:10 PM, Zach Oakes wrote:
> Can you elaborate on what you are trying to say? As I mentioned, I already
> ran "codesign -dv MyApp.app", and it does indeed show "version=2". Yet, I
> still get the error from Apple after uploading.
Sorry, I had read your poset a little while
Not sure, but that is what is different from what I have that works.
Everything else seemed to match up, including the forced overriding of the
signatures.
On Nov 9, 2014, at 5:23 PM, Zach Oakes wrote:
> In the bash script I linked, everything but jspawnhelper gets the full
> (user-supplied)
In the bash script I linked, everything but jspawnhelper gets the full
(user-supplied) entitlements. Do you think that is the problem?
On Sun, Nov 9, 2014 at 7:13 PM, Danno Ferrin
wrote:
> What are your entitlements? For javapackager we sign only the master
> package with real user supplied ent
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 sign
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
26 matches
Mail list logo
