From pslack at wavedna.com  Tue Nov  4 22:38:36 2014
From: pslack at wavedna.com (Peter J Slack)
Date: Tue, 4 Nov 2014 17:38:36 -0500
Subject: <AWT Dev> Drag and Drop crash jdk 1.8.0_25
In-Reply-To: <CALitSbvVMofYa6r-_RPyPmJ+r5mvYqo_MkR2cpuEKuRnqhbbNg@mail.gmail.com>
References: <CALitSbvVMofYa6r-_RPyPmJ+r5mvYqo_MkR2cpuEKuRnqhbbNg@mail.gmail.com>
Message-ID: <CALitSbu2sWWvcNzoZ1Zv0i4NsX4t97BCtehgsiOLgLk1Exm=yQ@mail.gmail.com>

Looks like this is fixed in 1.9 ..

On Thu, Oct 30, 2014 at 1:06 PM, Peter J Slack <pslack at wavedna.com> wrote:

> Hello to all fine folks,
>
> We are very grateful for open source and communities, I hope the following
> is useful.
>
> We've managed to embed openjdk 1.8.0_25 in the mac version of our product
> and it runs very well. However,  we've encountered a problem with drag and
> drop, putting this out there to see if there is any more insights or any
> fixes available.
>
> we have discovered this portion of code, it looks like one of the
> references is bad when it checks the references
>
>
> http://cr.openjdk.java.net/~pchelko/8006941/webrev.03/src/macosx/native/sun/awt/CDragSource.m.cdiff.html
>
>
> here is our crash log:
>
>
> Process:         LiquidRhythm [28369]
> Path:
>  /Applications/LiquidRhythm.app/Contents/MacOS/./LiquidRhythm
> Identifier:      com.wavedna.liquidrhythm.app
> Version:         1.4.2 (1.4.2)
> Code Type:       X86-64 (Native)
> Parent Process:  bash [28220]
> Responsible:     Terminal [1082]
> User ID:         501
>
> Date/Time:       2014-10-29 18:43:46.564 -0400
> OS Version:      Mac OS X 10.9.4 (13E28)
> Report Version:  11
> Anonymous UUID:  408B5E9C-DE6F-0A34-177B-0812033DF562
>
> Sleep/Wake UUID: EFB703F2-9CB3-4C94-ADA5-DF0FD214DB9F
>
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
>
> Exception Type:  EXC_BAD_ACCESS (SIGABRT)
> Exception Codes: KERN_INVALID_ADDRESS at 0x000000000000000c
>
> VM Regions Near 0xc:
> -->
>     __TEXT                 0000000100000000-0000000100005000 [   20K]
> r-x/rwx SM=COW  /Applications/LiquidRhythm.app/Contents/MacOS/LiquidRhythm
>
> Application Specific Information:
> abort() called
>
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib         0x00007fff8d737866 __pthread_kill + 10
> 1   libsystem_pthread.dylib        0x00007fff9418935c pthread_kill + 92
> 2   libsystem_c.dylib              0x00007fff8cc59b1a abort + 125
> 3   libjvm.dylib                   0x0000000107e7002b os::abort(bool) + 25
> 4   libjvm.dylib                   0x0000000107d1de03
> jniCheck::validate_handle(JavaThread*, _jobject*) + 119
> 5   libjvm.dylib                   0x0000000107d1f02a
> checked_jni_NewGlobalRef + 207
> 6   JavaNativeFoundation           0x000000011b91bd07 JNFNewGlobalRef + 31
> 7   libawt_lwawt.dylib             0x0000000120c5fdb5 -[CDragSource
> init:component:control:transferable:triggerEvent:dragPosX:dragPosY:modifiers:clickCount:timeStamp:dragImage:dragImageOffsetX:dragImageOffsetY:sourceActions:formats:formatMap:]
> + 151
> 8   libawt_lwawt.dylib             0x0000000120c6036e
> __Java_sun_lwawt_macosx_CDragSourceContextPeer_createNativeDragSource_block_invoke_1
> + 427
> 9   JavaNativeFoundation           0x000000011b92053d +[JNFRunLoop
> _performDirectBlock:] + 12
> 10  com.apple.Foundation           0x00007fff8bd4813e
> __NSThreadPerformPerform + 229
> 11  com.apple.CoreFoundation       0x00007fff920035b1
> __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
> 12  com.apple.CoreFoundation       0x00007fff91ff4c62
> __CFRunLoopDoSources0 + 242
> 13  com.apple.CoreFoundation       0x00007fff91ff43ef __CFRunLoopRun + 831
> 14  com.apple.CoreFoundation       0x00007fff91ff3e75
> CFRunLoopRunSpecific + 309
> 15  com.apple.HIToolbox            0x00007fff9269ba0d
> RunCurrentEventLoopInMode + 226
> 16  com.apple.HIToolbox            0x00007fff9269b685
> ReceiveNextEventCommon + 173
> 17  com.apple.HIToolbox            0x00007fff9269b5bc
> _BlockUntilNextEventMatchingListInModeWithFilter + 65
> 18  com.apple.AppKit               0x00007fff8ef3424e _DPSNextEvent + 1434
> 19  com.apple.AppKit               0x00007fff8ef3389b -[NSApplication
> nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
> 20  libswt-pi-cocoa-4430.jnilib    0x000000011f627d6a
> Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSendSuper__Lorg_eclipse_swt_internal_cocoa_objc_1super_2JJJJZ
> + 122
> 21  ???                            0x000000010bdfcbde 0 + 4494183390
> 22  ???                            0x000000010bdfedc4 0 + 4494192068
> 23  libjvm.dylib                   0x0000000107ce7516
> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*,
> Thread*) + 1710
> 24  libjvm.dylib                   0x0000000107d1c58b
> jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType,
> _jmethodID*, JNI_ArgumentPusher*, Thread*) + 447
> 25  libjvm.dylib                   0x0000000107d14bfd
> jni_CallStaticLongMethodV + 268
> 26  libjvm.dylib                   0x0000000107d28476
> checked_jni_CallStaticLongMethodV + 277
> 27  libswt-cocoa-4430.jnilib       0x000000011f2c8f92 callback + 1344
> 28  libswt-cocoa-4430.jnilib       0x000000011f2ae525 fn3_6 + 90
> 29  libswt-pi-cocoa-4430.jnilib    0x000000011f623bc2
> Java_org_eclipse_swt_internal_cocoa_OS_objc_1msgSend__JJJJJZ + 79
> 30  ???                            0x000000010bdfc84d 0 + 4494182477
> 31  ???                            0x000000010be8f424 0 + 4494783524
> 32  ???                            0x000000010ab187e4 0 + 4474374116
> 33  ???                            0x000000010ab187e4 0 + 4474374116
> 34  ???                            0x000000010ab18710 0 + 4474373904
> 35  ???                            0x000000010ab18710 0 + 4474373904
> 36  ???                            0x000000010ab18710 0 + 4474373904
> 37  ???                            0x000000010ab114e7 0 + 4474344679
> 38  libjvm.dylib                   0x0000000107ce7516
> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*,
> Thread*) + 1710
> 39  libjvm.dylib                   0x0000000107eb60be
> Reflection::invoke(instanceKlassHandle, methodHandle, Handle, bool,
> objArrayHandle, BasicType, objArrayHandle, bool, Thread*) + 3576
> 40  libjvm.dylib                   0x0000000107eb65d8
> Reflection::invoke_method(oopDesc*, Handle, objArrayHandle, Thread*) + 364
> 41  libjvm.dylib                   0x0000000107d35b98 JVM_InvokeMethod +
> 358
> 42  ???                            0x000000010ab26694 0 + 4474431124
> 43  ???                            0x000000010ab18710 0 + 4474373904
> 44  ???                            0x000000010ab18710 0 + 4474373904
> 45  ???                            0x000000010ab187e4 0 + 4474374116
> 46  ???                            0x000000010ab18710 0 + 4474373904
> 47  ???                            0x000000010ab1898d 0 + 4474374541
> 48  ???                            0x000000010ab1898d 0 + 4474374541
> 49  ???                            0x000000010ab114e7 0 + 4474344679
> 50  libjvm.dylib                   0x0000000107ce7516
> JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*,
> Thread*) + 1710
> 51  libjvm.dylib                   0x0000000107d1c93b
> jni_invoke_nonstatic(JNIEnv_*, JavaValue*, _jobject*, JNICallType,
> _jmethodID*, JNI_ArgumentPusher*, Thread*) + 773
> 52  libjvm.dylib                   0x0000000107d0e53b jni_CallIntMethodV
> + 248
> 53  libjvm.dylib                   0x0000000107d21416
> checked_jni_CallIntMethod + 379
> 54  eclipse_1605.so                0x000000010029a43a startJavaJNI + 2090
> 55  eclipse_1605.so                0x0000000100296d12 _run + 6114
> 56  eclipse_1605.so                0x00000001002951fa run + 410
> 57  com.wavedna.liquidrhythm.app   0x00000001000023ef original_main + 1946
> 58  com.wavedna.liquidrhythm.app   0x00000001000029dc main + 1237
> 59  com.wavedna.liquidrhythm.app   0x0000000100001af8 start + 52
>
>
> PJ Slack, P.Eng
>
> --
> Senior Software Developer / IT Administrator
> Work:  (416) 466-9283
> Fax  :  (866)  855-2605
>
> <http://www.wavedna.com/>
>    <https://www.facebook.com/waveDNA>  <http://www.twitter.com/wavedna>
> <http://www.youtube.com/wavedna>  <http://www.soundcloud.com/wavedna>
> <https://plus.google.com/+Wavedna/posts>  <http://instagram.com/wavedna>
> <http://www.linkedin.com/company/wavedna>
>



-- 
Senior Software Developer / IT Administrator
Work:  (416) 466-9283
Fax  :  (866)  855-2605

<http://www.wavedna.com/>
   <https://www.facebook.com/waveDNA>  <http://www.twitter.com/wavedna>
<http://www.youtube.com/wavedna>  <http://www.soundcloud.com/wavedna>
<https://plus.google.com/+Wavedna/posts>  <http://instagram.com/wavedna>
<http://www.linkedin.com/company/wavedna>

From zsoakes at gmail.com  Sun Nov  9 21:26:34 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Sun, 9 Nov 2014 16:26:34 -0500
Subject: MAS codesign requirements break Java app signing
Message-ID: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>

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

From mik3hall at gmail.com  Mon Nov 10 00:06:13 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 9 Nov 2014 18:06:13 -0600
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
Message-ID: <3694C0E5-3A15-4C3F-8C21-D60607DDC7FC@gmail.com>

On Nov 9, 2014, at 3:26 PM, Zach Oakes <zsoakes at gmail.com> wrote:

> so I think I am using v2 signatures. 

https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205

Code Signing Changes in OS X Mavericks

To determine which version of resource envelope a code signature has, use codesign -dv and note the version of the sealed resources, like this:

$ codesign -dv Chess.app/
[...]
Sealed Resources version=2 rules=15 files=53


Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From zsoakes at gmail.com  Mon Nov 10 00:10:39 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Sun, 9 Nov 2014 19:10:39 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <3694C0E5-3A15-4C3F-8C21-D60607DDC7FC@gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<3694C0E5-3A15-4C3F-8C21-D60607DDC7FC@gmail.com>
Message-ID: <CACSa_niu7=+JpMLjWHroA3h-3KeWxGr20ZDcdO6wmr6eqdQV1A@mail.gmail.com>

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.

On Sun, Nov 9, 2014 at 7:06 PM, Michael Hall <mik3hall at gmail.com> wrote:

> On Nov 9, 2014, at 3:26 PM, Zach Oakes <zsoakes at gmail.com> wrote:
>
> so I think I am using v2 signatures.
>
>
>
> https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205
>
> Code Signing Changes in OS X Mavericks
>
> To determine which version of resource envelope a code signature has,
> use codesign -dv and note the version of the sealed resources, like this:
>
> $ codesign -dv Chess.app/
> [...]
> Sealed Resources version=2 rules=15 files=53
>
>
> Michael Hall
>
> *trz *nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>
> *HalfPipe *Java 6/7 shell app
> http://www195.pair.com/mik3hall/index.html#halfpipe
>
> *AppConverter *convert Apple jvm to openjdk apps
> http://www195.pair.com/mik3hall/index.html#appconverter
>
>
>
>
>
>

From danno.ferrin at oracle.com  Mon Nov 10 00:13:22 2014
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Sun, 9 Nov 2014 17:13:22 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
Message-ID: <9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>

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


From zsoakes at gmail.com  Mon Nov 10 00:23:13 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Sun, 9 Nov 2014 19:23:13 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
Message-ID: <CACSa_nhE7ajd7T8THeriLeJd6+v5pMQxRNYGW09NubS4kBvhuQ@mail.gmail.com>

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 <danno.ferrin at 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 <zsoakes at 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
>
>

From danno.ferrin at oracle.com  Mon Nov 10 00:24:11 2014
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Sun, 9 Nov 2014 17:24:11 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_nhE7ajd7T8THeriLeJd6+v5pMQxRNYGW09NubS4kBvhuQ@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhE7ajd7T8THeriLeJd6+v5pMQxRNYGW09NubS4kBvhuQ@mail.gmail.com>
Message-ID: <1517F4E3-ABF0-47E9-8457-25228E0F71CD@oracle.com>

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 <zsoakes at gmail.com> wrote:

> 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 <danno.ferrin at 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 <zsoakes at 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
> 
> 


From mik3hall at gmail.com  Mon Nov 10 00:24:59 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 9 Nov 2014 18:24:59 -0600
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_niu7=+JpMLjWHroA3h-3KeWxGr20ZDcdO6wmr6eqdQV1A@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<3694C0E5-3A15-4C3F-8C21-D60607DDC7FC@gmail.com>
	<CACSa_niu7=+JpMLjWHroA3h-3KeWxGr20ZDcdO6wmr6eqdQV1A@mail.gmail.com>
Message-ID: <B5AC1531-0AA7-43E4-9784-70F014DB62EF@gmail.com>

On Nov 9, 2014, at 6:10 PM, Zach Oakes <zsoakes at gmail.com> 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 back and missed the significance of that until after I focused on the "so I think I am using v2 signatures. ? and did some checking myself to see how you would display that.
Not sure, otherwise, the Mavericks section also has?
	? It records substantially all files by default. There are no default "holes" (omit rules).
	? It records nested code (frameworks, dylibs, helper tools and apps, plug-ins, etc.) by recording their code signature for verification.
	? It records symbolic links. Version 1 resource envelopes ignore symlinks.

There was some mention awhile ago I think that a jli(?) lib used a symbolic link or something like that? That might of been mentioned on the old Apple java-dev list. Would cause a problem now. You could ?ls? all the files in your embedded jre checking for any sum

> version=2 rules=12 files=7

Since it is now ?all files? you could verify the file count in your bundle is actually 7? 

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From mik3hall at gmail.com  Mon Nov 10 00:32:38 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 9 Nov 2014 18:32:38 -0600
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <B5AC1531-0AA7-43E4-9784-70F014DB62EF@gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<3694C0E5-3A15-4C3F-8C21-D60607DDC7FC@gmail.com>
	<CACSa_niu7=+JpMLjWHroA3h-3KeWxGr20ZDcdO6wmr6eqdQV1A@mail.gmail.com>
	<B5AC1531-0AA7-43E4-9784-70F014DB62EF@gmail.com>
Message-ID: <8C056210-B24A-4FC0-9D65-1B039E259897@gmail.com>

On Nov 9, 2014, at 6:24 PM, Michael Hall <mik3hall at gmail.com> wrote:

> There was some mention awhile ago I think that a jli(?) lib used a symbolic link or something like that? That might of been mentioned on the old Apple java-dev list. Would cause a problem now. You could ?ls? all the files in your embedded jre checking for any sum

Sorry again, I was going to say checking for ?any? symbolic links. I found what I think was the java-dev jli thread. Might not apply since it seems applet plugin specific.
http://lists.apple.com/archives/java-dev/2012/Oct/msg00009.html

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From zsoakes at gmail.com  Mon Nov 10 01:01:38 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Sun, 9 Nov 2014 20:01:38 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <1517F4E3-ABF0-47E9-8457-25228E0F71CD@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhE7ajd7T8THeriLeJd6+v5pMQxRNYGW09NubS4kBvhuQ@mail.gmail.com>
	<1517F4E3-ABF0-47E9-8457-25228E0F71CD@oracle.com>
Message-ID: <CACSa_ngXjV=7ojh-5O+wObduuPtggHAg0fUeXPxWqZZyK6guJg@mail.gmail.com>

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 PM, Danno Ferrin <danno.ferrin at oracle.com>
wrote:

> 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 <zsoakes at gmail.com> wrote:
>
> 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 <danno.ferrin at 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 <zsoakes at 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
>>
>>
>
>

From nick at transparentech.com  Mon Nov 10 08:37:39 2014
From: nick at transparentech.com (Nicholas Rahn)
Date: Mon, 10 Nov 2014 09:37:39 +0100
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <8C056210-B24A-4FC0-9D65-1B039E259897@gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<3694C0E5-3A15-4C3F-8C21-D60607DDC7FC@gmail.com>
	<CACSa_niu7=+JpMLjWHroA3h-3KeWxGr20ZDcdO6wmr6eqdQV1A@mail.gmail.com>
	<B5AC1531-0AA7-43E4-9784-70F014DB62EF@gmail.com>
	<8C056210-B24A-4FC0-9D65-1B039E259897@gmail.com>
Message-ID: <CAP3J-cM7m2MhUX+xGAnNnv81MjU1zZ3J1b0TgKdcH1Xw7JKmaQ@mail.gmail.com>

Here's the link to the libjli linking issue:

https://bitbucket.org/infinitekind/appbundler/issue/1/appbundle-built-on-mac-osx-1095-cannot-be

But it doesn't sound like what you're seeing because it happens on the
command line while signing.

Nick


On Mon, Nov 10, 2014 at 1:32 AM, Michael Hall <mik3hall at gmail.com> wrote:

> On Nov 9, 2014, at 6:24 PM, Michael Hall <mik3hall at gmail.com> wrote:
>
> > There was some mention awhile ago I think that a jli(?) lib used a
> symbolic link or something like that? That might of been mentioned on the
> old Apple java-dev list. Would cause a problem now. You could ?ls? all the
> files in your embedded jre checking for any sum
>
> Sorry again, I was going to say checking for ?any? symbolic links. I found
> what I think was the java-dev jli thread. Might not apply since it seems
> applet plugin specific.
> http://lists.apple.com/archives/java-dev/2012/Oct/msg00009.html
>
> Michael Hall
>
> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>
> HalfPipe Java 6/7 shell app
> http://www195.pair.com/mik3hall/index.html#halfpipe
>
> AppConverter convert Apple jvm to openjdk apps
> http://www195.pair.com/mik3hall/index.html#appconverter
>
>
>
>
>
>

From mik3hall at gmail.com  Mon Nov 10 10:14:17 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 10 Nov 2014 04:14:17 -0600
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CAP3J-cM7m2MhUX+xGAnNnv81MjU1zZ3J1b0TgKdcH1Xw7JKmaQ@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<3694C0E5-3A15-4C3F-8C21-D60607DDC7FC@gmail.com>
	<CACSa_niu7=+JpMLjWHroA3h-3KeWxGr20ZDcdO6wmr6eqdQV1A@mail.gmail.com>
	<B5AC1531-0AA7-43E4-9784-70F014DB62EF@gmail.com>
	<8C056210-B24A-4FC0-9D65-1B039E259897@gmail.com>
	<CAP3J-cM7m2MhUX+xGAnNnv81MjU1zZ3J1b0TgKdcH1Xw7JKmaQ@mail.gmail.com>
Message-ID: <3C402749-4350-40DE-99F9-809374B8BC12@gmail.com>

On Nov 10, 2014, at 2:37 AM, Nicholas Rahn <nick at transparentech.com> wrote:

> But it doesn't sound like what you're seeing because it happens on the
> command line while signing.

Doesn?t codesign have a command line ?verify" parameter? I wonder what that indicates?

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From zsoakes at gmail.com  Mon Nov 10 14:42:56 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 09:42:56 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <3C402749-4350-40DE-99F9-809374B8BC12@gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<3694C0E5-3A15-4C3F-8C21-D60607DDC7FC@gmail.com>
	<CACSa_niu7=+JpMLjWHroA3h-3KeWxGr20ZDcdO6wmr6eqdQV1A@mail.gmail.com>
	<B5AC1531-0AA7-43E4-9784-70F014DB62EF@gmail.com>
	<8C056210-B24A-4FC0-9D65-1B039E259897@gmail.com>
	<CAP3J-cM7m2MhUX+xGAnNnv81MjU1zZ3J1b0TgKdcH1Xw7JKmaQ@mail.gmail.com>
	<3C402749-4350-40DE-99F9-809374B8BC12@gmail.com>
Message-ID: <CACSa_ngyXT+=fhz7L4mDi4P2kXY1ekx1aG82nBGZ4H5jGhvdog@mail.gmail.com>

I tried "codesign --verify --verbose=1" and got this:

MyApp.app/: valid on disk

MyApp.app/: satisfies its Designated Requirement

On Mon, Nov 10, 2014 at 5:14 AM, Michael Hall <mik3hall at gmail.com> wrote:

> On Nov 10, 2014, at 2:37 AM, Nicholas Rahn <nick at transparentech.com>
> wrote:
>
> > But it doesn't sound like what you're seeing because it happens on the
> > command line while signing.
>
> Doesn't codesign have a command line "verify" parameter? I wonder what
> that indicates?
>
> Michael Hall
>
> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>
> HalfPipe Java 6/7 shell app
> http://www195.pair.com/mik3hall/index.html#halfpipe
>
> AppConverter convert Apple jvm to openjdk apps
> http://www195.pair.com/mik3hall/index.html#appconverter
>
>
>
>
>
>

From zsoakes at gmail.com  Mon Nov 10 15:25:04 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 10:25:04 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
Message-ID: <CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>

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.ferrin at 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 <zsoakes at 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
>
>

From danno.ferrin at oracle.com  Mon Nov 10 15:26:58 2014
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Mon, 10 Nov 2014 08:26:58 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
Message-ID: <ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>

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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
> 
> 


From zsoakes at gmail.com  Mon Nov 10 15:38:18 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 10:38:18 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
Message-ID: <CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>

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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>
>>
>
>

From dalibor.topic at oracle.com  Mon Nov 10 15:42:36 2014
From: dalibor.topic at oracle.com (dalibor topic)
Date: Mon, 10 Nov 2014 16:42:36 +0100
Subject: Swing Look And Feel for Yosemite
In-Reply-To: <35BF613F-908A-4639-86BF-0670B13F89DC@eteks.com>
References: <mailman.18220.1411862678.10816.macosx-port-dev@openjdk.java.net>
	<35BF613F-908A-4639-86BF-0670B13F89DC@eteks.com>
Message-ID: <5460DCEC.5010908@oracle.com>

Hi,

Since you're asking about Swing, it may be better to raise this on the 
swing-dev mailing list.

cheers,
dalibor topic

On 20.10.2014 14:48, Emmanuel Puybaret wrote:
> Hi,
>
> OS X 10.10 Yosemite is out now and unless I missed something, Swing look and feel in new Java 7u72 / 8u25 wasn't prepared to welcome the changes in the user interface.
> When can we expect a new version of Java that will integrate these changes? How can I eventually help?
>
> Best regards,
> --
> Emmanuel PUYBARET
> Email  : puybaret at eteks.com
> Web    : http://www.eteks.com
>           http://www.sweethome3d.com
>

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

From zsoakes at gmail.com  Mon Nov 10 15:41:07 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 10:41:07 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
Message-ID: <CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>

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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>
>>>
>>
>>
>

From paul_t100 at fastmail.fm  Mon Nov 10 15:53:53 2014
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Mon, 10 Nov 2014 15:53:53 +0000
Subject: Swing Look And Feel for Yosemite
In-Reply-To: <5460DCEC.5010908@oracle.com>
References: <mailman.18220.1411862678.10816.macosx-port-dev@openjdk.java.net>	<35BF613F-908A-4639-86BF-0670B13F89DC@eteks.com>
	<5460DCEC.5010908@oracle.com>
Message-ID: <5460DF91.2030501@fastmail.fm>

On 10/11/2014 15:42, dalibor topic wrote:
> Hi,
>
> Since you're asking about Swing, it may be better to raise this on the 
> swing-dev mailing list.
>
> cheers,
> dalibor topic
I dont see why as the issue is very much specific to OSX

Paul

From zsoakes at gmail.com  Mon Nov 10 15:59:06 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 10:59:06 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
Message-ID: <CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>

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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>>
>>>>
>>>
>>>
>>
>

From hs at tagtraum.com  Mon Nov 10 16:02:15 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Mon, 10 Nov 2014 17:02:15 +0100
Subject: Swing Look And Feel for Yosemite
In-Reply-To: <5460DF91.2030501@fastmail.fm>
References: <mailman.18220.1411862678.10816.macosx-port-dev@openjdk.java.net>	<35BF613F-908A-4639-86BF-0670B13F89DC@eteks.com>
	<5460DCEC.5010908@oracle.com> <5460DF91.2030501@fastmail.fm>
Message-ID: <BE0A1BDD-834A-402A-BABA-A22749CDCFC2@tagtraum.com>


> I dont see why as the issue is very much specific to OSX

Agreed, but I guess the Swing people unfortunately don't necessarily read this list..

-hendrik


From danno.ferrin at oracle.com  Mon Nov 10 16:24:10 2014
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Mon, 10 Nov 2014 09:24:10 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
Message-ID: <E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>

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 <zsoakes at 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 <zsoakes at gmail.com <mailto:zsoakes at 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 <zsoakes at gmail.com <mailto:zsoakes at 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.ferrin at oracle.com <mailto:danno.ferrin at 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 <zsoakes at gmail.com <mailto:zsoakes at 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.ferrin at oracle.com <mailto:danno.ferrin at 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 <zsoakes at gmail.com <mailto:zsoakes at 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 <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
>> 
>> 
> 
> 
> 
> 


From puybaret at eteks.com  Mon Nov 10 17:09:48 2014
From: puybaret at eteks.com (Emmanuel Puybaret)
Date: Mon, 10 Nov 2014 18:09:48 +0100
Subject: Swing Look And Feel for Yosemite
In-Reply-To: <mailman.25669.1415636656.10816.macosx-port-dev@openjdk.java.net>
References: <mailman.25669.1415636656.10816.macosx-port-dev@openjdk.java.net>
Message-ID: <876F2B5D-56B5-4373-AE50-1B73A913004A@eteks.com>

>>> Since you're asking about Swing, it may be better to raise this on the 
>>> swing-dev mailing list.
>> 
>> I dont see why as the issue is very much specific to OSX
> 
> Agreed, but I guess the Swing people unfortunately don't necessarily read this list..

I think there's a need for a clarification. I already that kind message here, which made me wonder if macosx-port-dev was still alive and useful.
If almost all requests should be forwarded elsewhere, shouldn't the project be stopped?
Thanks for your advice
--
Emmanuel 


From danno.ferrin at oracle.com  Mon Nov 10 17:09:50 2014
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Mon, 10 Nov 2014 10:09:50 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
Message-ID: <B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>

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 <zsoakes at 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.ferrin at oracle.com <mailto:danno.ferrin at 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 <zsoakes at gmail.com <mailto:zsoakes at 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 <zsoakes at gmail.com <mailto:zsoakes at 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 <zsoakes at gmail.com <mailto:zsoakes at 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.ferrin at oracle.com <mailto:danno.ferrin at 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 <zsoakes at gmail.com <mailto:zsoakes at 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.ferrin at oracle.com <mailto:danno.ferrin at 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 <zsoakes at gmail.com <mailto:zsoakes at 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 <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
>>> 
>>> 
>> 
>> 
>> 
>> 
> 
> 


From zsoakes at gmail.com  Mon Nov 10 17:06:18 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 12:06:18 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
Message-ID: <CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>

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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>

From zsoakes at gmail.com  Mon Nov 10 17:27:44 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 12:27:44 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
Message-ID: <CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>

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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>

From zsoakes at gmail.com  Mon Nov 10 17:33:48 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 12:33:48 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
Message-ID: <CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>

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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>

From david.dehaven at oracle.com  Mon Nov 10 17:45:59 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 10 Nov 2014 09:45:59 -0800
Subject: Swing Look And Feel for Yosemite
In-Reply-To: <876F2B5D-56B5-4373-AE50-1B73A913004A@eteks.com>
References: <mailman.25669.1415636656.10816.macosx-port-dev@openjdk.java.net>
	<876F2B5D-56B5-4373-AE50-1B73A913004A@eteks.com>
Message-ID: <1F83F1A8-80FD-45D4-8948-DAA572DCF484@oracle.com>



>>>> Since you're asking about Swing, it may be better to raise this on the 
>>>> swing-dev mailing list.
>>> 
>>> I dont see why as the issue is very much specific to OSX
>> 
>> Agreed, but I guess the Swing people unfortunately don't necessarily read this list..
> 
> I think there's a need for a clarification. I already that kind message here, which made me wonder if macosx-port-dev was still alive and useful.
> If almost all requests should be forwarded elsewhere, shouldn't the project be stopped?
> Thanks for your advice

We still use it for the occasional generic "Java 7/8/9 on Mac" question that comes up from time to time. It is far preferable that the question be posted to the more specific lists, but sometimes it isn't clear where that belongs. There's enough of us monitoring the list that we can provide guidance on where to go but not enough that it should be used for all Mac specific questions.

-DrD-


From danno.ferrin at oracle.com  Mon Nov 10 19:46:54 2014
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Mon, 10 Nov 2014 12:46:54 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
Message-ID: <DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>

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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 


From steve at weblite.ca  Mon Nov 10 20:29:21 2014
From: steve at weblite.ca (Steve Hannah)
Date: Mon, 10 Nov 2014 12:29:21 -0800
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
Message-ID: <CABiRg+Snk5uMX32J7j63GSSLda6GfhOePU_S0bTu0dfSM2Q1JA@mail.gmail.com>

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.ferrin at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>


-- 
Steve Hannah
Web Lite Solutions Corp.

From zsoakes at gmail.com  Mon Nov 10 20:41:58 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 15:41:58 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
Message-ID: <CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>

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.ferrin at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

From zsoakes at gmail.com  Mon Nov 10 20:43:49 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 15:43:49 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CABiRg+Snk5uMX32J7j63GSSLda6GfhOePU_S0bTu0dfSM2Q1JA@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CABiRg+Snk5uMX32J7j63GSSLda6GfhOePU_S0bTu0dfSM2Q1JA@mail.gmail.com>
Message-ID: <CACSa_nhs_VswYFCLj-nnQHwSpGNXkrKAmebL1Ttasq=3VDxsqg@mail.gmail.com>

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 <steve at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>
>
> --
> Steve Hannah
> Web Lite Solutions Corp.
>

From danno.ferrin at oracle.com  Mon Nov 10 21:10:02 2014
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Mon, 10 Nov 2014 14:10:02 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
Message-ID: <4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>

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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 


From javalists at cbfiddle.com  Mon Nov 10 21:28:44 2014
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 10 Nov 2014 13:28:44 -0800
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
Message-ID: <B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>

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.ferrin at 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.
> 


From zsoakes at gmail.com  Mon Nov 10 22:17:22 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 17:17:22 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
Message-ID: <CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>

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 <javalists at 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.ferrin at 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.
> >
>
>

From mik3hall at gmail.com  Tue Nov 11 00:30:16 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 10 Nov 2014 18:30:16 -0600
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
	<CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
Message-ID: <A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>

On Nov 10, 2014, at 4:17 PM, Zach Oakes <zsoakes at gmail.com> wrote:

> With the Ant task, I already can manually edit my Info.plist so that's not
> an issue. 

I have browsed through where this thread has gone and may of missed some things and aren?t yet using javapackager for anything so do not know how to translate appbundler related to that structure. Also I?m not aware of openjdk changes to appbundler if there have been any of those.
appbundler set java.library.path to <whatever.app>/Contents/MacOS
dylib?s put there should automatically be found. 

Classpath was automatically set to any jars, and only jars, included in the Java directory. That also included a Classes directory. You could locate resources in there off of classpath. 

What I thought was something missed was a way to access resources that you did not want in classpath. I had this need in one application and so included my own JavaApp directory, not in classpath.

If you are manually setting class path you probably shouldn?t be. What appbundler had should meet most needs? It shouldn?t be needed and could have something to do with sandboxing failing.
 
Not sure I?ve seen or had any other thoughts myself on why you get the v2 message. If the -dv looks correct and the codesign verifies. The file count on the -dv looked strange given all files are now supposed to be included and you have an embedded jre. Didn?t you only show like 7 files on the -dv?

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter





From zsoakes at gmail.com  Tue Nov 11 00:32:55 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 19:32:55 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
Message-ID: <CACSa_nixS-8oma6Ftg9dTMQeEk3hxUcH1GMNdPoEZEDs_pZiFw@mail.gmail.com>

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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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 <zsoakes at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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.ferrin at 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 <zsoakes at 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

From zsoakes at gmail.com  Tue Nov 11 00:46:08 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 19:46:08 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
	<CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
	<A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>
Message-ID: <CACSa_nikFpJgN3K221kX1Qkt9TTfVUVefTSNrcnZsf=71xmd2w@mail.gmail.com>

Well here is the full output of "codesign -dv MyApp.app" for the app
generated via appbundler:

Executable=/path/to/MyApp.app/Contents/MacOS/JavaAppLauncher
Identifier=info.oakleaf.myapp
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=286 flags=0x0(none) hashes=5+5 location=embedded
Signature size=4351
Signed Time=Nov 10, 2014, 7:41:39 PM
Info.plist entries=17
TeamIdentifier=445UCQ79D9
Sealed Resources version=2 rules=12 files=7
Internal requirements count=1 size=204

On Mon, Nov 10, 2014 at 7:30 PM, Michael Hall <mik3hall at gmail.com> wrote:

> On Nov 10, 2014, at 4:17 PM, Zach Oakes <zsoakes at gmail.com> wrote:
>
> > With the Ant task, I already can manually edit my Info.plist so that's
> not
> > an issue.
>
> I have browsed through where this thread has gone and may of missed some
> things and aren't yet using javapackager for anything so do not know how to
> translate appbundler related to that structure. Also I'm not aware of
> openjdk changes to appbundler if there have been any of those.
> appbundler set java.library.path to <whatever.app>/Contents/MacOS
> dylib's put there should automatically be found.
>
> Classpath was automatically set to any jars, and only jars, included in
> the Java directory. That also included a Classes directory. You could
> locate resources in there off of classpath.
>
> What I thought was something missed was a way to access resources that you
> did not want in classpath. I had this need in one application and so
> included my own JavaApp directory, not in classpath.
>
> If you are manually setting class path you probably shouldn't be. What
> appbundler had should meet most needs? It shouldn't be needed and could
> have something to do with sandboxing failing.
>
> Not sure I've seen or had any other thoughts myself on why you get the v2
> message. If the -dv looks correct and the codesign verifies. The file count
> on the -dv looked strange given all files are now supposed to be included
> and you have an embedded jre. Didn't you only show like 7 files on the -dv?
>
> Michael Hall
>
> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>
> HalfPipe Java 6/7 shell app
> http://www195.pair.com/mik3hall/index.html#halfpipe
>
> AppConverter convert Apple jvm to openjdk apps
> http://www195.pair.com/mik3hall/index.html#appconverter
>
>
>
>
>

From mik3hall at gmail.com  Tue Nov 11 01:03:48 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 10 Nov 2014 19:03:48 -0600
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_nikFpJgN3K221kX1Qkt9TTfVUVefTSNrcnZsf=71xmd2w@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
	<CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
	<A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>
	<CACSa_nikFpJgN3K221kX1Qkt9TTfVUVefTSNrcnZsf=71xmd2w@mail.gmail.com>
Message-ID: <08DA599A-5302-4CE6-85A1-9D63D40DE5C0@gmail.com>

On Nov 10, 2014, at 6:46 PM, Zach Oakes <zsoakes at gmail.com> wrote:

> Sealed Resources version=2 rules=12 files=7

The files=7 still seems strange.

I re-read the Mavericks part of the earlier mentioned TN. Still not entirely clear on the resource envelope thing though.

From farther in the TN this is supposed to be a ?Gatekeeper?-like verification
codesign --verify --deep --verbose=2 Foo.app
does it show any problems?

You can manually tweak Info.plist?s for testing, or as a matter of habit for me, pre-signed tweaks of course. Developer tools I think pops up it?s own application or you can text edit it as plain xml.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From zsoakes at gmail.com  Tue Nov 11 01:13:18 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 20:13:18 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <08DA599A-5302-4CE6-85A1-9D63D40DE5C0@gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
	<CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
	<A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>
	<CACSa_nikFpJgN3K221kX1Qkt9TTfVUVefTSNrcnZsf=71xmd2w@mail.gmail.com>
	<08DA599A-5302-4CE6-85A1-9D63D40DE5C0@gmail.com>
Message-ID: <CACSa_ngyZq6r5qD3R91UhLPeLpYwUQmv_hHpeWqnn6-8Yrag8A@mail.gmail.com>

I actually get a similar result when I run "codesign -dv" on the app bundle
created by javapackager, except it says files=6. As far as your other
command, I get this when I run it on the one created by appbundler:

MyApp.app/: valid on disk
MyApp.app/: satisfies its Designated Requirement

On Mon, Nov 10, 2014 at 8:03 PM, Michael Hall <mik3hall at gmail.com> wrote:

> On Nov 10, 2014, at 6:46 PM, Zach Oakes <zsoakes at gmail.com> wrote:
>
> Sealed Resources version=2 rules=12 files=7
>
>
> The files=7 still seems strange.
>
> I re-read the Mavericks part of the earlier mentioned TN. Still not
> entirely clear on the resource envelope thing though.
>
> From farther in the TN this is supposed to be a "Gatekeeper"-like
> verification
> codesign --verify --deep --verbose=2 Foo.app
> does it show any problems?
>
> You can manually tweak Info.plist's for testing, or as a matter of habit
> for me, pre-signed tweaks of course. Developer tools I think pops up it's
> own application or you can text edit it as plain xml.
>
> Michael Hall
>
> *trz *nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>
> *HalfPipe *Java 6/7 shell app
> http://www195.pair.com/mik3hall/index.html#halfpipe
>
> *AppConverter *convert Apple jvm to openjdk apps
> http://www195.pair.com/mik3hall/index.html#appconverter
>
>
>
>
>
>

From mik3hall at gmail.com  Tue Nov 11 01:20:48 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 10 Nov 2014 19:20:48 -0600
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngyZq6r5qD3R91UhLPeLpYwUQmv_hHpeWqnn6-8Yrag8A@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
	<CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
	<A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>
	<CACSa_nikFpJgN3K221kX1Qkt9TTfVUVefTSNrcnZsf=71xmd2w@mail.gmail.com>
	<08DA599A-5302-4CE6-85A1-9D63D40DE5C0@gmail.com>
	<CACSa_ngyZq6r5qD3R91UhLPeLpYwUQmv_hHpeWqnn6-8Yrag8A@mail.gmail.com>
Message-ID: <2B944706-26EA-42D9-A584-566F891F445F@gmail.com>

On Nov 10, 2014, at 7:13 PM, Zach Oakes <zsoakes at gmail.com> wrote:

> I actually get a similar result when I run "codesign -dv" on the app bundle created by javapackager, except it says files=6. As far as your other command, I get this when I run it on the one created by app bundler:

Obviously isn?t including all the files in the jre? I?m a little surprised if that is less than the number of total files in the bundle even if you only count the jre as one.

> MyApp.app/: valid on disk
> MyApp.app/: satisfies its Designated Requirement

It would be nice if you could find something else that didn?t like the signature for some reason. It might be easier then to figure out why it doesn?t like it. But that doesn?t seem to happen.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From zsoakes at gmail.com  Tue Nov 11 01:37:22 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Mon, 10 Nov 2014 20:37:22 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <2B944706-26EA-42D9-A584-566F891F445F@gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
	<CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
	<A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>
	<CACSa_nikFpJgN3K221kX1Qkt9TTfVUVefTSNrcnZsf=71xmd2w@mail.gmail.com>
	<08DA599A-5302-4CE6-85A1-9D63D40DE5C0@gmail.com>
	<CACSa_ngyZq6r5qD3R91UhLPeLpYwUQmv_hHpeWqnn6-8Yrag8A@mail.gmail.com>
	<2B944706-26EA-42D9-A584-566F891F445F@gmail.com>
Message-ID: <CACSa_ngvPcV_dPS8pUm9hc_wJoNCGUdPwksGig6ERgmbYi4z6g@mail.gmail.com>

I have no idea what "files" refers to, so I can't comment on that. The JRE
is definitely inside the app bundle. Do your apps show a large number?

On Mon, Nov 10, 2014 at 8:20 PM, Michael Hall <mik3hall at gmail.com> wrote:

> On Nov 10, 2014, at 7:13 PM, Zach Oakes <zsoakes at gmail.com> wrote:
>
> > I actually get a similar result when I run "codesign -dv" on the app
> bundle created by javapackager, except it says files=6. As far as your
> other command, I get this when I run it on the one created by app bundler:
>
> Obviously isn't including all the files in the jre? I'm a little surprised
> if that is less than the number of total files in the bundle even if you
> only count the jre as one.
>
> > MyApp.app/: valid on disk
> > MyApp.app/: satisfies its Designated Requirement
>
> It would be nice if you could find something else that didn't like the
> signature for some reason. It might be easier then to figure out why it
> doesn't like it. But that doesn't seem to happen.
>
> Michael Hall
>
> trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>
> HalfPipe Java 6/7 shell app
> http://www195.pair.com/mik3hall/index.html#halfpipe
>
> AppConverter convert Apple jvm to openjdk apps
> http://www195.pair.com/mik3hall/index.html#appconverter
>
>
>
>
>
>

From mik3hall at gmail.com  Tue Nov 11 01:56:14 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Mon, 10 Nov 2014 19:56:14 -0600
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngvPcV_dPS8pUm9hc_wJoNCGUdPwksGig6ERgmbYi4z6g@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com>
	<CACSa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
	<A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>
	<CACSa_nikFpJgN3K221kX1Qkt9TTfVUVefTSNrcnZsf=71xmd2w@mail.gmail.com>
	<08DA599A-5302-4CE6-85A1-9D63D40DE5C0@gmail.com>
	<CACSa_ngyZq6r5qD3R91UhLPeLpYwUQmv_hHpeWqnn6-8Yrag8A@mail.gmail.com>
	<2B944706-26EA-42D9-A584-566F891F445F@gmail.com>
	<CACSa_ngvPcV_dPS8pUm9hc_wJoNCGUdPwksGig6ERgmbYi4z6g@mail.gmail.com>
Message-ID: <E3959C26-835F-429F-8B52-ED63F090B30B@gmail.com>

On Nov 10, 2014, at 7:37 PM, Zach Oakes <zsoakes at gmail.com> wrote:

> I have no idea what "files" refers to, so I can't comment on that. The JRE is definitely inside the app bundle. Do your apps show a large number?


Mine seem to only have files=1. Which maybe means unsigned. Or I didn?t use ?deep?? t thought I had signed one or two of them. Nothing in MAS yet though. 
Came across this...
http://stackoverflow.com/questions/25152451/are-mac-app-store-code-sign-resource-envelopes-always-version-1
might have something useful for you.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From philip.race at oracle.com  Tue Nov 11 02:02:21 2014
From: philip.race at oracle.com (Phil Race)
Date: Mon, 10 Nov 2014 18:02:21 -0800
Subject: Swing Look And Feel for Yosemite
In-Reply-To: <1F83F1A8-80FD-45D4-8948-DAA572DCF484@oracle.com>
References: <mailman.25669.1415636656.10816.macosx-port-dev@openjdk.java.net>	<876F2B5D-56B5-4373-AE50-1B73A913004A@eteks.com>
	<1F83F1A8-80FD-45D4-8948-DAA572DCF484@oracle.com>
Message-ID: <54616E2D.50403@oracle.com>

On 11/10/14 9:45 AM, David DeHaven wrote:
> We still use it for the occasional generic "Java 7/8/9 on Mac" question that comes up from time to time. It is far preferable that the question be posted to the more specific lists, but sometimes it isn't clear where that belongs. There's enough of us monitoring the list that we can provide guidance on where to go but not enough that it should be used for all Mac specific question

And, some Apple folks might be still peeking at this list in their free 
time and chime
in with useful information. But they are very unlikely to be reading the 
swing list.
Just don't take that as meaning all mac questions go here first. After 
all we don't
have a "windows port list" or an "ubuntu port list" ...


-phil.

From paul_t100 at fastmail.fm  Tue Nov 11 08:48:19 2014
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Tue, 11 Nov 2014 08:48:19 +0000
Subject: Swing Look And Feel for Yosemite
In-Reply-To: <54616E2D.50403@oracle.com>
References: <mailman.25669.1415636656.10816.macosx-port-dev@openjdk.java.net>	<876F2B5D-56B5-4373-AE50-1B73A913004A@eteks.com>	<1F83F1A8-80FD-45D4-8948-DAA572DCF484@oracle.com>
	<54616E2D.50403@oracle.com>
Message-ID: <5461CD53.8060508@fastmail.fm>

On 11/11/2014 02:02, Phil Race wrote:
> On 11/10/14 9:45 AM, David DeHaven wrote:
>> We still use it for the occasional generic "Java 7/8/9 on Mac" 
>> question that comes up from time to time. It is far preferable that 
>> the question be posted to the more specific lists, but sometimes it 
>> isn't clear where that belongs. There's enough of us monitoring the 
>> list that we can provide guidance on where to go but not enough that 
>> it should be used for all Mac specific question
>
> And, some Apple folks might be still peeking at this list in their 
> free time and chime
> in with useful information. But they are very unlikely to be reading 
> the swing list.
Yep
> Just don't take that as meaning all mac questions go here first. After 
> all we don't
> have a "windows port list" or an "ubuntu port list" ...
>
No, but Apple a special case there is alot more divergence between the 
OSX Gui, and the Windows/Linux guis. And Apple seems much more likely to 
making changes in its new OS versions that scupper us java devs.

Paul

From danno.ferrin at oracle.com  Tue Nov 11 17:12:19 2014
From: danno.ferrin at oracle.com (Danno Ferrin)
Date: Tue, 11 Nov 2014 10:12:19 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngyZq6r5qD3R91UhLPeLpYwUQmv_hHpeWqnn6-8Yrag8A@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<9D464272-F59F-4FC1-8A37-9818F7A3F21B@oracle.com>
	<CACSa_nhUy-UpKyS2+WVd-TvB9mVz3WDEkC=NS8OfKM6Uv8_TnA@mail.gmail.com>
	<ACCD02A7-621E-41E5-9F0F-334AF63FA486@oracle.com>
	<CACSa_njYKLk5a03M+Dnaj=NrfqrQeUxJmkhH7y8pCLuaZTKHnw@mail.gmail.com>
	<CACSa_nid84dtHjy+52aCgbER-33prthZ+Os9BD=o56Q0B9hjog@mail.gmail.com>
	<CACSa_niuSWkc=LOZq2LtOkSK3CZmPt6r-PjMjy6FZdRz+TCqjw@mail.gmail.com>
	<E764E50F-C3C1-4080-914C-CAF9BF54C275@oracle.com>
	<CACSa_ngZ4zR8r3udxwxEVUjUiMuqPJNouNuTUU9ZsBW53jcmrQ@mail.gmail.com>
	<B948BAF2-DA5E-46CA-A98A-257344744A1C@oracle.com>
	<CACSa_njAZb+=dOXQXPn0y1beKBvo7AWpmJBVsRWSC+5by39B4w@mail.gmail.com>
	<CACSa_ngOUD9v=5oRvgn-BN9Z+UoH_GuWLNgO3GSaaWM1Ndx35g@mail.gmail.com>
	<DE9BC2A8-6980-45A7-84AB-887BAD80044C@oracle.com>
	<CACSa_ngWAfzEHJeyXd=vfeaC_+j6=3YCTS6qmY+owcL3A361aw@mail.gmail.com>
	<4F0ADB52-96CF-4BDA-8786-A188841B0DBA@oracle.com>
	<B1FD96CA-5EA9-47A6-A406-0974324029EC@cbfiddle.com> <CAC!
	Sa_nhRtTVmwUfdagMH42bQNTqQGx0DxGK7g63zip6tq27mwQ@mail.gmail.com>
	<A6CE8062-17B2-463D-AD25-BC7E4EA7F608@gmail.com>
	<CACSa_nikFpJgN3K221kX1Qkt9TTfVUVefTSNrcnZsf=71xmd2w@mail.gmail.com>
	<08DA599A-5302-4CE6-85A1-9D63D40DE5C0@gmail.com>
	<CACSa_ngyZq6r5qD3R91UhLPeLpYwUQmv_hHpeWqnn6-8Yrag8A@mail.gmail.com>
Message-ID: <FC9DA2B5-EFE7-42C5-818A-991FA3E5F797@oracle.com>

When packaging hte JRE for javapackger, we remove a lot of stuff.  One of those is the symbolic link in .../Contents/MacOS/libjli.dylib.  That would explain why files=6 as opposed to files=7


On Nov 10, 2014, at 6:13 PM, Zach Oakes <zsoakes at gmail.com> wrote:

> I actually get a similar result when I run "codesign -dv" on the app bundle
> created by javapackager, except it says files=6. As far as your other
> command, I get this when I run it on the one created by appbundler:
> 
> MyApp.app/: valid on disk
> MyApp.app/: satisfies its Designated Requirement
> 
> On Mon, Nov 10, 2014 at 8:03 PM, Michael Hall <mik3hall at gmail.com> wrote:
> 
>> On Nov 10, 2014, at 6:46 PM, Zach Oakes <zsoakes at gmail.com> wrote:
>> 
>> Sealed Resources version=2 rules=12 files=7
>> 
>> 
>> The files=7 still seems strange.
>> 
>> I re-read the Mavericks part of the earlier mentioned TN. Still not
>> entirely clear on the resource envelope thing though.
>> 
>> From farther in the TN this is supposed to be a "Gatekeeper"-like
>> verification
>> codesign --verify --deep --verbose=2 Foo.app
>> does it show any problems?
>> 
>> You can manually tweak Info.plist's for testing, or as a matter of habit
>> for me, pre-signed tweaks of course. Developer tools I think pops up it's
>> own application or you can text edit it as plain xml.
>> 
>> Michael Hall
>> 
>> *trz *nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz
>> 
>> *HalfPipe *Java 6/7 shell app
>> http://www195.pair.com/mik3hall/index.html#halfpipe
>> 
>> *AppConverter *convert Apple jvm to openjdk apps
>> http://www195.pair.com/mik3hall/index.html#appconverter
>> 
>> 
>> 
>> 
>> 
>> 


From jfinley at tech4learning.com  Tue Nov 11 21:44:27 2014
From: jfinley at tech4learning.com (Jessica Finley)
Date: Tue, 11 Nov 2014 14:44:27 -0700
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
Message-ID: <F19E6C25-4671-4731-8C68-CA322320EFD0@tech4learning.com>

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 anyhow, it?s still pending a review from a human now).  Here?s what I noticed and did differently?

Looking at my fully signed app bundle, I noticed that the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/_CodeSignature folder contained different items than the MyApp.app/Contents/_CodeSignature folder.. particularly, it contained a CodeResources file which made me wonder if perhaps this was what was triggering our error (as the Apple documentation mentions not using the --resource-rules flag anymore, which I was never doing in the first place, but according to the codesign documentation, if resource rules are not specified, it does its best to make something up, and I?m guessing it was making something up for my embedded JRE bundle).

After some tinkering around, I discovered that the appbundler removes a particular folder, the 1.8.0.jre/Contents/MacOS folder when it stuffs the JRE into MyApp.app.  Well, when this folder is removed, codesign behaves much differently than when this folder is present.  When this folder is present, the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/_CodeSignature folder contains the same item as the MyApp.app/Contents/_CodeSignature folder.  So, after I did my usual bundling script, I went in and manually restored the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/MacOS folder, then I signed everything as I usually do? and surely enough, the app is accepted by Application Loader.

So, given that you are still struggling with javapackager, you might want to try this simple solution, as it might be all that you need to keep your existing flow working.

-Jess


On Nov 9, 2014, at 2:26 PM, Zach Oakes <zsoakes at 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



From zsoakes at gmail.com  Wed Nov 12 07:21:24 2014
From: zsoakes at gmail.com (Zach Oakes)
Date: Wed, 12 Nov 2014 02:21:24 -0500
Subject: MAS codesign requirements break Java app signing
In-Reply-To: <F19E6C25-4671-4731-8C68-CA322320EFD0@tech4learning.com>
References: <CACSa_ngWBBxLWun+rEHqwN7+fT22bVf6JxcSQxNxUzKk7JY+Ag@mail.gmail.com>
	<F19E6C25-4671-4731-8C68-CA322320EFD0@tech4learning.com>
Message-ID: <CACSa_ng71QoVv8D9GEf4UnRBwLX1pOw21xWWNTFVZ_BxHRg-Xg@mail.gmail.com>

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 11, 2014 at 4:44 PM, Jessica Finley <jfinley at tech4learning.com>
wrote:

> 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 anyhow, it's still pending a review from a human now).  Here's
> what I noticed and did differently...
>
> Looking at my fully signed app bundle, I noticed that the
> MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/_CodeSignature folder
> contained different items than the MyApp.app/Contents/_CodeSignature
> folder.. particularly, it contained a CodeResources file which made me
> wonder if perhaps this was what was triggering our error (as the Apple
> documentation mentions not using the --resource-rules flag anymore, which I
> was never doing in the first place, but according to the codesign
> documentation, if resource rules are not specified, it does its best to
> make something up, and I'm guessing it was making something up for my
> embedded JRE bundle).
>
> After some tinkering around, I discovered that the appbundler removes a
> particular folder, the 1.8.0.jre/Contents/MacOS folder when it stuffs the
> JRE into MyApp.app.  Well, when this folder is removed, codesign behaves
> much differently than when this folder is present.  When this folder is
> present, the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/_CodeSignature
> folder contains the same item as the MyApp.app/Contents/_CodeSignature
> folder.  So, after I did my usual bundling script, I went in and manually
> restored the MyApp.app/Contents/PlugIns/1.8.0.jre/Contents/MacOS folder,
> then I signed everything as I usually do... and surely enough, the app is
> accepted by Application Loader.
>
> So, given that you are still struggling with javapackager, you might want
> to try this simple solution, as it might be all that you need to keep your
> existing flow working.
>
> -Jess
>
>
> On Nov 9, 2014, at 2:26 PM, Zach Oakes <zsoakes at 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
>
>
>

From Kustaa.Nyholm at planmeca.com  Wed Nov 12 18:39:05 2014
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Wed, 12 Nov 2014 20:39:05 +0200
Subject: JOGL/HiDPI/Retina support on Java 8
In-Reply-To: <F19E6C25-4671-4731-8C68-CA322320EFD0@tech4learning.com>
Message-ID: <D08975BB.A1D5A%kustaa.nyholm@planmeca.com>

This is probably the wrong list but since I hand around here
and JOGL forum did not come up with anything I thought I'd ask
here.

I've moved to Java 8 and now my JOGL / javax.media.opengl.awt.GLJPanel
draws its stuff in the lower left quarter of the display on my MacBook
Retina.

An obvious remedy is just to double the size of my glViewport() but how
do I know when I need to do this and when I don't -- ie without testing
I'm assuming that on non retina displays I must not do this.

I've google up and down but I've find no definite source on how HiDPI
displays are supported by Java 8. Just realized I'm actually using
Oracle JDK 8 if it makes a difference....

Feel free to direct me to a better list or forum or better yet to the
actual documentation.

br Kusti




This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general.

From Kustaa.Nyholm at planmeca.com  Wed Nov 12 19:06:22 2014
From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm)
Date: Wed, 12 Nov 2014 21:06:22 +0200
Subject: JOGL/HiDPI/Retina support on Java 8
In-Reply-To: <D08975BB.A1D5A%kustaa.nyholm@planmeca.com>
Message-ID: <D0897C47.A1D98%kustaa.nyholm@planmeca.com>

On 12/11/2014 20:39, "Kustaa Nyholm" <Kustaa.Nyholm at planmeca.com> wrote:

>This is probably the wrong list but since I hand around here
>and JOGL forum did not come up with anything I thought I'd ask
>here.
>
>I've moved to Java 8 and now my JOGL / javax.media.opengl.awt.GLJPanel
>draws its stuff in the lower left quarter of the display on my MacBook
>Retina.
>
>An obvious remedy is just to double the size of my glViewport() but how
>do I know when I need to do this and when I don't -- ie without testing
>I'm assuming that on non retina displays I must not do this.
>
>I've google up and down but I've find no definite source on how HiDPI
>displays are supported by Java 8. Just realized I'm actually using
>Oracle JDK 8 if it makes a difference....
>
>Feel free to direct me to a better list or forum or better yet to the
>actual documentation.
>
>br Kusti

As soon as I posted this I found the answer, here for posterity:


http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/o
pengl/GLDrawable.html#getSurfaceWidth%28%29
http://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/javax/media/n
ativewindow/NativeSurface.html#getSurfaceWidth%28%29


br Kusti


This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general.

From thomas.stuefe at gmail.com  Wed Nov 19 10:47:59 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 19 Nov 2014 11:47:59 +0100
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's JavaVM
	Frameworks
Message-ID: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>

Hi all,

I tried to build a very simple launcher (simple c program) for a customer
to show how to build a java launcher; launcher loads libjvm.dylib using
dlopen() and resolves JNI_CreateJavaVM via dlsym().

On MacOS, when running, in JNI_CreateJavaVM I get the same error as
mentioned in JDK-7131356
<https://bugs.openjdk.java.net/browse/JDK-7131356> ("No
Java runtime present, requesting install").

I was able to work around the issue by locally providing implementations
for "JLI_MemAlloc" (and, for balance, realloc and free too) and exporting
them, even though the functions make no sense in the launcher. This symbol
seems to be a trigger for Apples JavaRuntimeServices framework to stop
complaining about missing java runtime. I am not even sure this function is
even called by the Apple framework.

So my questions are:
- does anyone know a better workaround?
- can we hope for a fix?

Thanks! and Kind Regards,

Thomas St?fe

From wmoore40 at gmail.com  Wed Nov 19 16:39:00 2014
From: wmoore40 at gmail.com (William Moore)
Date: Wed, 19 Nov 2014 17:39:00 +0100
Subject: FileDialog on OS X 10.10 with Java 8u25
In-Reply-To: <mailman.16970.1411060609.10816.macosx-port-dev@openjdk.java.net>
References: <mailman.16970.1411060609.10816.macosx-port-dev@openjdk.java.net>
Message-ID: <9740043A-91AA-4CB3-8440-7CD202EA62AA@gmail.com>

Hello

I'm using a java.awt.FileDialog to select a file for opening. I get the following error when I make the FileDialog visible:

<error>

2014-11-19 17:09:10.925 java[11592:4309058] Unable to simultaneously satisfy constraints:
(
    "<NSAutoresizingMaskLayoutConstraint:0x7f8993cc3df0 h=--& v=--& V:[FI_TBrowserBackgroundView:0x7f8993d17a50(0)]>",
    "<NSAutoresizingMaskLayoutConstraint:0x7f8993cc3800 h=-&- v=-&- V:|-(0)-[FI_TListScrollView:0x7f8993d54790]   (Names: '|':FI_TBrowserBackgroundView:0x7f8993d17a50 )>",
    "<NSAutoresizingMaskLayoutConstraint:0x7f8993cc37b0 h=-&- v=-&- V:[FI_TListScrollView:0x7f8993d54790]-(0)-|   (Names: '|':FI_TBrowserBackgroundView:0x7f8993d17a50 )>",
    "<NSAutoresizingMaskLayoutConstraint:0x7f8993cbe180 h=-&- v=-&- V:[NSClipView:0x7f8993bb5f50]-(15)-|   (Names: '|':FI_TListScrollView:0x7f8993d54790 )>",
    "<NSAutoresizingMaskLayoutConstraint:0x7f8993cbe130 h=-&- v=-&- V:|-(0)-[NSClipView:0x7f8993bb5f50]   (Names: '|':FI_TListScrollView:0x7f8993d54790 )>"
)

Will attempt to recover by breaking constraint 
<NSAutoresizingMaskLayoutConstraint:0x7f8993cbe180 h=-&- v=-&- V:[NSClipView:0x7f8993bb5f50]-(15)-|   (Names: '|':FI_TListScrollView:0x7f8993d54790 )>

Set the NSUserDefault NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints to YES to have -[NSWindow visualizeConstraints:] automatically called when this happens.  And/or, break on objc_exception_throw to catch this in the debugger.

</error>

This is on OS X 10.10 with Java 8u25. Perhaps it was happening before and I didn?t notice. Everything still works once the dialog is open, but that is quite slow.

Is there anything I can do to remove the error?

Thanks in advance

William

From david.dehaven at oracle.com  Thu Nov 20 17:31:54 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 20 Nov 2014 09:31:54 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
Message-ID: <083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>


Are you linking against JavaVM.framework? If you just need the JNI headers, it's better to use those provided in the JDK (the headers are even correct these days...). You shouldn't need to link anything to just open and use libjvm. This is generally true for JNI libraries too since native methods are dynamically looked up by symbol name. So, instead of "-framework JavaVM" use "-I${JDK_HOME}/include -I${JDK_HOME}/include/darwin" and it will find jni.h (assuming JDK_HOME is defined and correct).

JLI (libjli) is a much more robust option for 7 and beyond, but the documentation around it is sparse. All of our launchers are just wrappers around JLI_Launch, it takes a lot of the hassle out of working with libjvm. Look in jdk/src/java.base/share/native/launcher/main.c (OpenJDK 9) for an example. You will still need to dlopen libjli.dylib and use dlsym to get JLI_Launch, it will handle opening libjvm for you.


You could also try the Java Packager, which will go a step further and create a native .app bundle for you.

-DrD-

> Hi all,
> 
> I tried to build a very simple launcher (simple c program) for a customer
> to show how to build a java launcher; launcher loads libjvm.dylib using
> dlopen() and resolves JNI_CreateJavaVM via dlsym().
> 
> On MacOS, when running, in JNI_CreateJavaVM I get the same error as
> mentioned in JDK-7131356
> <https://bugs.openjdk.java.net/browse/JDK-7131356> ("No
> Java runtime present, requesting install").
> 
> I was able to work around the issue by locally providing implementations
> for "JLI_MemAlloc" (and, for balance, realloc and free too) and exporting
> them, even though the functions make no sense in the launcher. This symbol
> seems to be a trigger for Apples JavaRuntimeServices framework to stop
> complaining about missing java runtime. I am not even sure this function is
> even called by the Apple framework.
> 
> So my questions are:
> - does anyone know a better workaround?
> - can we hope for a fix?
> 
> Thanks! and Kind Regards,
> 
> Thomas St?fe


From thomas.stuefe at gmail.com  Thu Nov 20 19:55:39 2014
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 20 Nov 2014 20:55:39 +0100
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
Message-ID: <CAA-vtUwuTrsgLCE6XzYt5h4=snPHiQpCtvd_0OEV4bgtYn7HVA@mail.gmail.com>

Hi David,

thanks! Sorry, I guess I left out some details in my original post, so here
is a bit more background:

We support a lot of platforms as well as JDK releases, so I wanted to keep
this testlauncher as platform neutral as possible and also it had to run
with older JDKs, so unfortunately JLI was not an option.

Right now the testlauncher works across all our Unices, it is very simple
portable C, just MacOS gave me a bit of a headache.

I think I do already what you suggest:
- I include jni.h (depending on whose jni.h I use, the platform dependent
include path for jni_md.h is sometimes needed, sometimes not.)
- create a new thread because on some platforms VM cannot run on primordial
thread
- load libjvm via dlopen(), resolve JNI_createJavaVM via dlsym()
- call JNI_createJavaVM()
- Load the main class, invoke the main method with the parameters given.

I link against libdl and libpthread and, on MacOS, against the framework
"ApplicationServices" (see below why). I do not link against any other
framework, nor against the libjvm itself.

On almost all platforms that worked nicely. On MacOS however I got two
errors:

1) first I ran into a SIGTRAP when dlopen()'ing the libjvm.dylib. When
debugging, I found that it happened when the libjvm.dylib loads the
libjava.dylib. The libjava.dylib needs the ApplicationServices framework,
but was not linked against it, so it was not self-contained. I guess that
is an error, but I was lazy and instead of fixing that, I linked the
launcher itself against that framework, even if the launcher does not need
it, and now the dlopen() worked.

2) Now, the libjvm.dylib was successfully loaded, and we called
JNI_CreateJavaVM. That caused the error mentioned in my first post ("No
Java runtime present, requesting install"). I googled and found that the
error message stems from Apple's JavaRuntimeSupport framework. There is a
nice summary by Gerard Ziemski in the comments section of JDK-7131356
<https://bugs.openjdk.java.net/browse/JDK-7131356> .

Apple suggests deferring load of the JavaRuntimeServices framework after
JNI_MemAlloc(). I could not do that but I could provide local variants of
JNI_MemAlloc() (very simple, just added "void* JNI_MemAlloc(size_t s) {
return malloc(s); }" to my testlauncher). My local variants of
JNI_MemAlloc() and JNI_MemFree() do the same as the JDK variants, so even
if they are intermixed no harm is done.

This worked - the error disappeared - so I guess the JavaRuntimeServices
framework tries to fish this symbol out of the air to see if it is running
within a valid Java VM process. Now my testlauncher worked on MacOS, I ran
a number of java programs with it and all is well.

But still, it is quite ugly, hence my original questions: do you know a
better workaround for this bug? And how far is the work on getting rid of
this dependency on the JavaRuntimeServices framework altogether? Is that
still the plan?

Thanks for your time!

Kind Regards, Thomas


On Thu, Nov 20, 2014 at 6:31 PM, David DeHaven <david.dehaven at oracle.com>
wrote:

>
> Are you linking against JavaVM.framework? If you just need the JNI
> headers, it's better to use those provided in the JDK (the headers are even
> correct these days...). You shouldn't need to link anything to just open
> and use libjvm. This is generally true for JNI libraries too since native
> methods are dynamically looked up by symbol name. So, instead of
> "-framework JavaVM" use "-I${JDK_HOME}/include
> -I${JDK_HOME}/include/darwin" and it will find jni.h (assuming JDK_HOME is
> defined and correct).
>
> JLI (libjli) is a much more robust option for 7 and beyond, but the
> documentation around it is sparse. All of our launchers are just wrappers
> around JLI_Launch, it takes a lot of the hassle out of working with libjvm.
> Look in jdk/src/java.base/share/native/launcher/main.c (OpenJDK 9) for an
> example. You will still need to dlopen libjli.dylib and use dlsym to get
> JLI_Launch, it will handle opening libjvm for you.
>
>
> You could also try the Java Packager, which will go a step further and
> create a native .app bundle for you.
>
> -DrD-
>
> > Hi all,
> >
> > I tried to build a very simple launcher (simple c program) for a customer
> > to show how to build a java launcher; launcher loads libjvm.dylib using
> > dlopen() and resolves JNI_CreateJavaVM via dlsym().
> >
> > On MacOS, when running, in JNI_CreateJavaVM I get the same error as
> > mentioned in JDK-7131356
> > <https://bugs.openjdk.java.net/browse/JDK-7131356> ("No
> > Java runtime present, requesting install").
> >
> > I was able to work around the issue by locally providing implementations
> > for "JLI_MemAlloc" (and, for balance, realloc and free too) and exporting
> > them, even though the functions make no sense in the launcher. This
> symbol
> > seems to be a trigger for Apples JavaRuntimeServices framework to stop
> > complaining about missing java runtime. I am not even sure this function
> is
> > even called by the Apple framework.
> >
> > So my questions are:
> > - does anyone know a better workaround?
> > - can we hope for a fix?
> >
> > Thanks! and Kind Regards,
> >
> > Thomas St?fe
>
>

From mik3hall at gmail.com  Thu Nov 20 22:17:46 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 20 Nov 2014 16:17:46 -0600
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <CAA-vtUwuTrsgLCE6XzYt5h4=snPHiQpCtvd_0OEV4bgtYn7HVA@mail.gmail.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<CAA-vtUwuTrsgLCE6XzYt5h4=snPHiQpCtvd_0OEV4bgtYn7HVA@mail.gmail.com>
Message-ID: <B340DE9B-4D92-4867-9314-DF54B050A320@gmail.com>

On Nov 20, 2014, at 1:55 PM, Thomas St?fe <thomas.stuefe at gmail.com> wrote:

> The libjava.dylib needs the ApplicationServices framework,
> but was not linked against it, so it was not self-contained. I guess that
> is an error

Somewhat OT maybe. But possibly this was to support AppleScript/Apple Event?s?
Apple by default provided a AppleScript JSR 223 engine.
Apple Event?s would be needed to handle a couple different Apple Events. One being 'open document? if your application wants to allow associated files that will launch it when a document is double clicked.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From mik3hall at gmail.com  Thu Nov 20 23:56:45 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Thu, 20 Nov 2014 17:56:45 -0600
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
Message-ID: <8444B1A2-1298-4D9B-85FF-2D0BF2C3959F@gmail.com>

On Nov 20, 2014, at 11:31 AM, David DeHaven <david.dehaven at oracle.com> wrote:

> Are you linking against JavaVM.framework?

If you?re not using Xcode but instead gcc somehow that would be?
-framework JavaVM
If you?re trying for a single launcher that will work with multiple versions of the framework. I?m not sure how that would work.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From david.dehaven at oracle.com  Sat Nov 22 00:07:32 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Fri, 21 Nov 2014 16:07:32 -0800
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <8444B1A2-1298-4D9B-85FF-2D0BF2C3959F@gmail.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<8444B1A2-1298-4D9B-85FF-2D0BF2C3959F@gmail.com>
Message-ID: <F52C549C-9645-4928-926B-8775402D63D0@oracle.com>


>> Are you linking against JavaVM.framework?
> 
> If you?re not using Xcode but instead gcc somehow that would be?
> -framework JavaVM
> If you?re trying for a single launcher that will work with multiple versions of the framework. I?m not sure how that would work.

Using -framework JavaVM used to be a means to getting jni.h in the header search path. Unfortunately it also links against the library which nowadays you do not want to do. Building against JavaRuntimeSupport and/or JavaNativeFoundation also pull in JavaVM.

-DrD-


From mik3hall at gmail.com  Sat Nov 22 00:33:42 2014
From: mik3hall at gmail.com (Michael Hall)
Date: Fri, 21 Nov 2014 18:33:42 -0600
Subject: Question about JDK-8024281 Mac OS X: stop relying on Apple's
	JavaVM Frameworks
In-Reply-To: <F52C549C-9645-4928-926B-8775402D63D0@oracle.com>
References: <CAA-vtUyq2LeUCWSATwp3QxNPK7TxKia85_Unr+tZGt6DU1dJTQ@mail.gmail.com>
	<083D26A5-FF4E-488D-BF40-4684041B20E3@oracle.com>
	<8444B1A2-1298-4D9B-85FF-2D0BF2C3959F@gmail.com>
	<F52C549C-9645-4928-926B-8775402D63D0@oracle.com>
Message-ID: <D71226EF-A916-4927-A527-0D11B54548DB@gmail.com>

On Nov 21, 2014, at 6:07 PM, David DeHaven <david.dehaven at oracle.com> wrote:

> Using -framework JavaVM used to be a means to getting jni.h in the header search path. Unfortunately it also links against the library which nowadays you do not want to do. Building against JavaRuntimeSupport and/or JavaNativeFoundation also pull in JavaVM.

If you mean you don?t want to do this to link against the old Apple that for me hasn?t been an issue, I don?t really use it anymore.  
But if you can?t include the framework that would probably complicate the compile either XCode or command line.
You could probably find an old version of the Apple launcher stub and just use that for that particular jvm without using your own launcher code?
It would require special handling. But this is getting old enough you might expect it to.

Michael Hall

trz nio.2 for OS X http://www195.pair.com/mik3hall/index.html#trz

HalfPipe Java 6/7 shell app http://www195.pair.com/mik3hall/index.html#halfpipe

AppConverter convert Apple jvm to openjdk apps http://www195.pair.com/mik3hall/index.html#appconverter






From ajgregory at gmail.com  Tue Nov 25 19:47:04 2014
From: ajgregory at gmail.com (AJ Gregory)
Date: Tue, 25 Nov 2014 11:47:04 -0800
Subject: Odd behavior with transparent window getting shadow after toggling
	visibility
Message-ID: <CADgN_Nqja1S10i4ShDMA_Am1t57xd1aeF3ik1E58MSgE5bWzbw@mail.gmail.com>

If you run the class below on a RETINA MacBook Pro (OSX 10.10) the first
time you see the JWindow it's a white circle with NO shadow, but then later
when it calls setVisible(false) and setVisible(true) the circle has a
shadow when it's made visible again which isn't right...

I can't reproduce on non-retina (OSX 10.9) so wondering if it's a retina
only issue?

Same behavior for both Java 7u71 and 8u25...

Anybody else experience this and have a work around?

Seems like a bug for sure unless I'm missing something...

import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;

public class TestMacShadow {
    public static void main(String[] args) {
        EventQueue.invokeLater(new Runnable() {
            public void run() {
                final JWindow window = new JWindow() {
                    public void paint(Graphics g) {
                        g.setColor(Color.WHITE);
                        g.fillOval(0, 0, getWidth(), getHeight());
                    }
                };

                window.setBackground(new Color(0, 0, 0, 0));
                window.setLocation(new Point(100, 100));
                window.setSize(new Dimension(300, 300));
                window.setAlwaysOnTop(true);
                window.setVisible(true);

                Timer t = new Timer(2000, new ActionListener() {
                    public void actionPerformed(ActionEvent actionEvent) {
                        window.setVisible(!window.isVisible());
                    }
                });

                t.setRepeats(true);
                t.start();
            }
        });
    }
}

From hs at tagtraum.com  Wed Nov 26 12:20:50 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Wed, 26 Nov 2014 13:20:50 +0100
Subject: Is JavaNativeFoundation still supported on OS X 10.10?
Message-ID: <7E991F42-DD22-4FB2-AA02-DF4BC7282CBE@tagtraum.com>

Hey..

I just upgraded to OS X 10.10 and unfortunately my JNI compile steps are now failing, because the headers for JavaNativeFoundation cannot be found anymore.

Specifically, given a file Test.m that contains only:

#import <JavaNativeFoundation/JavaNativeFoundation.h>

The following gcc call:

gcc -DTARGET_OS_MAC -Wall -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/ -F/System/Library/Frameworks/JavaVM.framework/Frameworks -mmacosx-version-min=10.7 -I/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/include/darwin -o Test.o -c Test.m

Fails with:

Test.m:1:9: fatal error: 'JavaNativeFoundation/JavaNativeFoundation.h' file not found
#import <JavaNativeFoundation/JavaNativeFoundation.h>
        ^
1 error generated.

The very same gcc call used to work on OS X 10.9.
I checked, and indeed the header files are missing in the JNF Framework.

Thanks for your help,

-hendrik

From hs at tagtraum.com  Wed Nov 26 15:42:22 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Wed, 26 Nov 2014 16:42:22 +0100
Subject: Is JavaNativeFoundation still supported on OS X 10.10?
In-Reply-To: <7E991F42-DD22-4FB2-AA02-DF4BC7282CBE@tagtraum.com>
References: <7E991F42-DD22-4FB2-AA02-DF4BC7282CBE@tagtraum.com>
Message-ID: <15F361D7-F024-434A-8FDF-118AD37856F7@tagtraum.com>

On Nov 26, 2014, at 13:20, Hendrik Schreiber <hs at tagtraum.com> wrote:
> 
> The very same gcc call used to work on OS X 10.9.
> I checked, and indeed the header files are missing in the JNF Framework.

OK - not sure why, but the headers have appeared.
Perhaps because I installed the XCode command line tools.

Odd.

-hendrik

From david.dehaven at oracle.com  Wed Nov 26 18:08:14 2014
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 26 Nov 2014 10:08:14 -0800
Subject: Is JavaNativeFoundation still supported on OS X 10.10?
In-Reply-To: <7E991F42-DD22-4FB2-AA02-DF4BC7282CBE@tagtraum.com>
References: <7E991F42-DD22-4FB2-AA02-DF4BC7282CBE@tagtraum.com>
Message-ID: <8C35205B-8E78-4EE2-80E4-D538B5806FA5@oracle.com>


> -F/System/Library/Frameworks/JavaVM.framework/Frameworks

I've stopped relying on any headers ever appearing in /System/Library/Frameworks, use ${SDKROOT}/System/Library/Frameworks instead.

If you're not using Xcode you can use xcrun to get a path to the SDK:
$ xcrun --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk

Older versions of xcrun didn't support that. For those you have to run:
$ xcodebuild -sdk macosx -showsdks -version

and parse the output with grep/sed/perl/whatever.

-DrD-


From hs at tagtraum.com  Thu Nov 27 09:23:56 2014
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 27 Nov 2014 10:23:56 +0100
Subject: Is JavaNativeFoundation still supported on OS X 10.10?
In-Reply-To: <8C35205B-8E78-4EE2-80E4-D538B5806FA5@oracle.com>
References: <7E991F42-DD22-4FB2-AA02-DF4BC7282CBE@tagtraum.com>
	<8C35205B-8E78-4EE2-80E4-D538B5806FA5@oracle.com>
Message-ID: <79D97309-AABE-49A3-AD32-7EF714DB4754@tagtraum.com>

On Nov 26, 2014, at 19:08, David DeHaven <david.dehaven at oracle.com> wrote:
> 
> 
>> -F/System/Library/Frameworks/JavaVM.framework/Frameworks
> 
> I've stopped relying on any headers ever appearing in /System/Library/Frameworks, use ${SDKROOT}/System/Library/Frameworks instead.

Good point.
Thanks, David!

-hendrik