Looks good.
/Erik
On 2019-03-29 04:30, Langer, Christoph wrote:
Hi Erik, Arno,
thanks for reviewing and spotting the $(JDK_BUNDLE_EXTENSION) macro. I
simply forgot it because I was copying the original code as it was pre
JDK-8200132. At that time, there was no $(JDK_BUNDLE_EXTENSION) macro yet.
I already verified that using $(JDK_BUNDLE_EXTENSION) will correctly
produce a zip bundle on Windows.
I’ll test whether standard images will still get build (without
legacy) as requested by Erik before pushing.
This is the updated webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8221610.1/
Thanks
Christoph
*From:*Erik Joelsson <erik.joels...@oracle.com>
*Sent:* Donnerstag, 28. März 2019 15:54
*To:* Zeller, Arno <arno.zel...@sap.com>; Langer, Christoph
<christoph.lan...@sap.com>; build-dev@openjdk.java.net
*Cc:* Schuenemann, Rene <rene.schuenem...@sap.com>
*Subject:* Re: RFR: 8221610: Resurrect (legacy) JRE bundle target
Hello,
On 2019-03-28 04:47, Zeller, Arno wrote:
Hi Christoph,
thanks for the patch. Just one small suggestion – I think you
could use the same extension for jdk archive also for the jre
archive in make/autoconf/spec.gmk.in?
Something like this:
JRE_BUNDLE_NAME := jre-$(BASE_NAME)_bin$(DEBUG_PART).
$(JDK_BUNDLE_EXTENSION)
I think this makes sense.
Otherwise this looks ok to me. Have you verified that it still works
when not building any legacy-images and no legacy-image is present in
the build dir?
Otherwise you will have a difference between jdk and jre archives
on windows and zip might be more common on windows. I think to get
a real zip in the end you might need more changes.
This is actually the only change needed. The makefile will figure out
the tool to use based on the extension.
Best regards,
Arno
*From:*Langer, Christoph
*Sent:* Donnerstag, 28. März 2019 10:07
*To:* build-dev@openjdk.java.net
<mailto:build-dev@openjdk.java.net>; Erik Joelsson
<erik.joels...@oracle.com> <mailto:erik.joels...@oracle.com>
*Cc:* Zeller, Arno <arno.zel...@sap.com>
<mailto:arno.zel...@sap.com>; Schuenemann, Rene
<rene.schuenem...@sap.com> <mailto:rene.schuenem...@sap.com>
*Subject:* RFR: 8221610: Resurrect (legacy) JRE bundle target
Hi build-dev,
today I’m coming up with kind of a backward oriented suggestion…
don’t know how well that would be received. Let’s see.
For JDK 11, with JDK-8200132 [0], the JRE build has been moved to
legacy.
There has been some discussion beforehand whether the JRE build
can completely be dropped or how far one can go removing the
support for it [1]. In the end the decision was made to at least
remove the JRE from the main targets and only offer some “legacy”
targets that would still build the JRE. Unfortunately, you were
under the assumption that nobody except Oracle would use the
bundle target and removed it as well [2]. Unfortunately, this
assumption was not quite true (and I was not there to raise my
concern ☹). In SapMachine builds, we use the bundle targets and we
are also still building JRE images for several stakeholders. So it
would really be good if we could get the JRE bundle target back.
At the moment we mimick the bundling in a shell script that is run
after the build.
I'm happy to hear that this got use outside of Oracle!
/Erik
So, I suggest to add back the BUILD_JRE_BUNDLE target in
Bundles.gmk and add an additional main target called
legacy-bundles which can be called for creating the JRE bundle.
Of course, this can go eventually when JRE support is finally
dropped for OpenJDK.
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8221610.0/
Bug: https://bugs.openjdk.java.net/browse/JDK-8221610
<https://bugs.openjdk.java.net/browse/JDK-8221610>
Thanks
Christoph
[0] https://bugs.openjdk.java.net/browse/JDK-8200132
<https://bugs.openjdk.java.net/browse/JDK-8200132>
[1]
https://mail.openjdk.java.net/pipermail/build-dev/2018-June/022249.html
[2]
https://mail.openjdk.java.net/pipermail/build-dev/2018-June/022274.html
