Re: RFR(S) : 8245610 : remove in-tree copy on gtest

2020-05-29 Thread René Schünemann
Hi all, I agree with Thomas. I think it would be beneficial to have a fallback when there is no gtest directory explicitly set. Also, running make target "run-test-gtest" now without "--with-gtest" results in a not so descriptive error message. make run-test-gtest Building target

Re: RFR: JDK-8238534

2020-02-13 Thread René Schünemann
wrote: > > Hello Rene, > > On 2020-02-12 02:54, René Schünemann wrote: > > Hello Erik, > > > > thank you for your guidance. > > I have implemented your requested changes. > > > > Updated WebRev: > > http://cr.openjdk.java.net/~rschuenemann/wr/

Re: RFR: JDK-8238534

2020-02-12 Thread René Schünemann
make, even if they already exist. Do you notice the same behavior? Rene On Tue, Feb 11, 2020 at 6:57 PM Erik Joelsson wrote: > > On 2020-02-11 01:08, René Schünemann wrote: > > Hello Erik, > > > > thank you for your review. Please see my answers below. > > > > Re

Re: RFR: JDK-8238534

2020-02-11 Thread René Schünemann
-server-release/images/jdk-bundle-signed/jdk-15.jdk: is already signed Can you confirm, that libjli.dylib doesn't need the entitlements? > /Erik > > On 2020-02-10 10:12, René Schünemann wrote: > > Hi Erik, > > > > I have implemented your requested changes. I think it is a lot cleaner

Re: RFR: JDK-8238534

2020-02-10 Thread René Schünemann
AM René Schünemann wrote: > > Hi Erik, > > thank you for your review and I totally agree with you. It would > definitely be better avoid temp dirs. > I will try to move the creation of the signed image to MacBundles.gmk > and then re-use the SetubBundleFile in Bundles.gmk. >

Re: RFR: JDK-8238534

2020-02-10 Thread René Schünemann
r the actual > bundling, even if most of the functionality in it is not used, just to > avoid more separate code paths than necessary. > > /Erik > > On 2020-02-07 02:05, René Schünemann wrote: > > For the Apple notarization process, the whole bundle in its final form > > has to

RFR: JDK-8238534

2020-02-07 Thread René Schünemann
For the Apple notarization process, the whole bundle in its final form has to be signed with the codesign tool. See the discussion here: https://bugs.openjdk.java.net/browse/JDK-8238225 This change copies all JDK/JRE files to a temporary directory, which is then passed to the codesign tool. The

Re: RFR: JDK-8235585: Enable macOS codesigning for all libraries and executables

2019-12-10 Thread René Schünemann
: Dienstag, 10. Dezember 2019 15:35 > > To: René Schünemann ; Langer, Christoph > > > > Cc: build-dev@openjdk.java.net > > Subject: Re: RFR: JDK-8235585: Enable macOS codesigning for all libraries > > and > > executables > > > > Looks good. > > >

Re: RFR: JDK-8235585: Enable macOS codesigning for all libraries and executables

2019-12-10 Thread René Schünemann
e it into JDK14 without special approval. > > Best regards > Christoph > > > > -Original Message- > > From: build-dev On Behalf Of René > > Schünemann > > Sent: Dienstag, 10. Dezember 2019 09:27 > > To: Erik Joelsson > > Cc: build-dev@ope

Re: RFR: JDK-8235585: Enable macOS codesigning for all libraries and executables

2019-12-10 Thread René Schünemann
ple codesign based implementation) > > On 2019-12-09 08:06, René Schünemann wrote: > > Here is the webrev: > > http://cr.openjdk.java.net/~goetz/wr19/rene/8235585-mac_notarization/01/ > > Generally looks good. > > NativeCompilation.gmk, line 1132 looks weirdly indented. The lin

Re: RFR: JDK-8235585: Enable macOS codesigning for all libraries and executables

2019-12-09 Thread René Schünemann
Here is the webrev: http://cr.openjdk.java.net/~goetz/wr19/rene/8235585-mac_notarization/01/ On Mon, Dec 9, 2019 at 5:05 PM René Schünemann wrote: > > Hi, > > for the macOS notarization process, all executables and libraries need > to be codesigned with hardened runtime (--

RFR: JDK-8235585: Enable macOS codesigning for all libraries and executables

2019-12-09 Thread René Schünemann
Hi, for the macOS notarization process, all executables and libraries need to be codesigned with hardened runtime (--options runtime) and secure timestamp (--timestamp) enabled. Additionally for the OpenJDK certain entitlements have to be set during codesigning: * com.apple.security.cs.allow-jit

Re: RFR: 8205091: AIX: build errors in hotspot after 8203641: Refactor String Deduplication into shared

2018-06-15 Thread René Schünemann
Hi Matthias, the name SI seems also quite "common" and may result in other naming clashes in the future. Maybe something more readable like STAT_IMPL? Please also change the name in the comment: // STAT: String Dedup Stat implementation Regards, Rene On Fri, Jun 15, 2018 at 9:47 AM, Baesken,