Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it] But, to sum up my comprehension... anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet). Is this correct? So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter. Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ... Cheers Jörg On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX.
Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12.
-- Kevin
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager. We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development. Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP. -- Kevin On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it]
But, to sum up my comprehension...
anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet).
Is this correct?
So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ...
Cheers Jörg
On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX.
Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12.
-- Kevin
Hi Kevin Thanks for the helpful reply. If you don't mind, I add my feedback here below. My concern is about the options -BserviceHint and -singleton which make javapackager one of the best things since sliced bread. It seems like next to no one is really aware of these valuable features, no wonder since they are by and large undocumented. So, people out there keep fiddling around with all kinds of service wrapper tools and also with strange approaches to ensure an app is started only once, completely unaware of the fact, that JDK 10 supports this out of the box, by the tip of a finger so to say. According to JDK-8200758, for Windows only msi is required deployment objective. Others only optional. Note in this regard that in contrary to exe (innosetup) deployment, msi installer lacks icon support for the installer itself and resulting msi installer is around 35% bigger in size. Documentation is also of concern. Luckily, the source is open to read, so one can for example find out, how to enable and read debug output for WinLauncherSvc using DebugView and that "-BserviceHint" option exists. Yippie ;-) Cheers Jörg -----Original Message----- From: Kevin Rushforth [mailto:kevin.rushforth@oracle.com] Sent: Donnerstag, 28. Juni 2018 00:31 To: Buchberger, Joerg <Joerg.Buchberger@pruftechnik.com>; core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager. We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development. Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP. -- Kevin On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it]
But, to sum up my comprehension...
anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet).
Is this correct?
So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ...
Cheers Jörg
On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX.
Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12.
-- Kevin
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.jav a.net_browse_JDK-2D8200758&d=DwIDaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFm xRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=k3PBuMbi PBU9Ni8nXxqYD_VD9uEULpswQedWmbRiF-4&s=vBSYLYnENsNahwwRNz0r-gPNrs90xST Ebm0wFA2iPWs&e=
Doesn’t jlink require a *fully* modularized application? I.e. no non-module dependencies. The packaging tool should work with all runnable Java applications, not just fully modularized ones. Modularization seems to be a bit of an effort and is one of the main reasons my application(s) are still stuck on Java 8. Scott
On Jun 27, 2018, at 6:30 PM, Kevin Rushforth <kevin.rushforth@oracle.com> wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it]
But, to sum up my comprehension...
anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet).
Is this correct?
So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ...
Cheers Jörg
On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX.
Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12.
-- Kevin
you can jlink without any/complete module info files by specifying the module names on the command line (--add-modules)as well. It produces a jre like Directory including Java launcher which allows additions on the classpath. -- https://Bernd.eckenfels.net ________________________________ From: core-libs-dev <core-libs-dev-bounces@openjdk.java.net> on behalf of Scott Palmer <swpalmer@gmail.com> Sent: Thursday, June 28, 2018 2:32:13 PM To: Kevin Rushforth Cc: core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool Doesn’t jlink require a *fully* modularized application? I.e. no non-module dependencies. The packaging tool should work with all runnable Java applications, not just fully modularized ones. Modularization seems to be a bit of an effort and is one of the main reasons my application(s) are still stuck on Java 8. Scott
On Jun 27, 2018, at 6:30 PM, Kevin Rushforth <kevin.rushforth@oracle.com> wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it]
But, to sum up my comprehension...
anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet).
Is this correct?
So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ...
Cheers Jörg
On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX.
Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12.
-- Kevin
no you can't, --add-modules requires the module to have a module-info, being an automatic module is not good enough. regards, Rémi ----- Mail original -----
De: "Bernd Eckenfels" <ecki@zusammenkunft.net> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Jeudi 28 Juin 2018 17:34:35 Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
you can jlink without any/complete module info files by specifying the module names on the command line (--add-modules)as well. It produces a jre like Directory including Java launcher which allows additions on the classpath.
-- https://Bernd.eckenfels.net ________________________________ From: core-libs-dev <core-libs-dev-bounces@openjdk.java.net> on behalf of Scott Palmer <swpalmer@gmail.com> Sent: Thursday, June 28, 2018 2:32:13 PM To: Kevin Rushforth Cc: core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Doesn’t jlink require a *fully* modularized application? I.e. no non-module dependencies. The packaging tool should work with all runnable Java applications, not just fully modularized ones.
Modularization seems to be a bit of an effort and is one of the main reasons my application(s) are still stuck on Java 8.
Scott
On Jun 27, 2018, at 6:30 PM, Kevin Rushforth <kevin.rushforth@oracle.com> wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it]
But, to sum up my comprehension...
anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet).
Is this correct?
So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ...
Cheers Jörg
On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX.
Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12.
-- Kevin
You can add-modules from the JDK (only), so if you „—add-modules lang.base,JDK.jcmd,jdk.crypto.mscapi“ you get a super compact JRE which still can start your app from the classpath. Gruss Bernd -- http://bernd.eckenfels.net Von: Remi Forax Gesendet: Donnerstag, 28. Juni 2018 22:05 An: Bernd Eckenfels Cc: core-libs-dev Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool no you can't, --add-modules requires the module to have a module-info, being an automatic module is not good enough. regards, Rémi ----- Mail original -----
De: "Bernd Eckenfels" <ecki@zusammenkunft.net> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Jeudi 28 Juin 2018 17:34:35 Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
you can jlink without any/complete module info files by specifying the module names on the command line (--add-modules)as well. It produces a jre like Directory including Java launcher which allows additions on the classpath.
-- https://Bernd.eckenfels.net ________________________________ From: core-libs-dev <core-libs-dev-bounces@openjdk.java.net> on behalf of Scott Palmer <swpalmer@gmail.com> Sent: Thursday, June 28, 2018 2:32:13 PM To: Kevin Rushforth Cc: core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Doesn’t jlink require a *fully* modularized application? I.e. no non-module dependencies. The packaging tool should work with all runnable Java applications, not just fully modularized ones.
Modularization seems to be a bit of an effort and is one of the main reasons my application(s) are still stuck on Java 8.
Scott
On Jun 27, 2018, at 6:30 PM, Kevin Rushforth <kevin.rushforth@oracle.com> wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it]
But, to sum up my comprehension...
anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet).
Is this correct?
So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ...
Cheers Jörg
On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX.
Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12.
-- Kevin
----- Mail original -----
De: "Bernd Eckenfels" <ecki@zusammenkunft.net> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Jeudi 28 Juin 2018 22:47:23 Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
You can add-modules from the JDK (only), so if you „—add-modules lang.base,JDK.jcmd,jdk.crypto.mscapi“ you get a super compact JRE which still can start your app from the classpath.
You mean you select by hand the modules of the JDK you need and use the classpath for your application, ok, that's work with jlink :)
Gruss Bernd
Rémi
Von: Remi Forax Gesendet: Donnerstag, 28. Juni 2018 22:05 An: Bernd Eckenfels Cc: core-libs-dev Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
no you can't, --add-modules requires the module to have a module-info, being an automatic module is not good enough.
regards, Rémi
----- Mail original -----
De: "Bernd Eckenfels" <ecki@zusammenkunft.net> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Jeudi 28 Juin 2018 17:34:35 Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
you can jlink without any/complete module info files by specifying the module names on the command line (--add-modules)as well. It produces a jre like Directory including Java launcher which allows additions on the classpath.
-- https://Bernd.eckenfels.net ________________________________ From: core-libs-dev <core-libs-dev-bounces@openjdk.java.net> on behalf of Scott Palmer <swpalmer@gmail.com> Sent: Thursday, June 28, 2018 2:32:13 PM To: Kevin Rushforth Cc: core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Doesn’t jlink require a *fully* modularized application? I.e. no non-module dependencies. The packaging tool should work with all runnable Java applications, not just fully modularized ones.
Modularization seems to be a bit of an effort and is one of the main reasons my application(s) are still stuck on Java 8.
Scott
On Jun 27, 2018, at 6:30 PM, Kevin Rushforth <kevin.rushforth@oracle.com> wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
On 6/27/2018 3:09 AM, Buchberger, Joerg wrote:
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I really mean it]
But, to sum up my comprehension...
anyone who placed their bets on javapackager, starting with last LTS Java 8 will be left in the rain with followup LTS Java 11, because their ain't neither javapackager (anymore), nor jpackager (yet).
Is this correct?
So, strategic choice boils down to either throw away all work done based on javapackager so far and the associated distribution concepts (reworking everything from scratch) or neglect Java 11 completely, thus placing all bets on jpackager really coming w/ Java 12 or even waiting for Java 14 as next LTS thereafter.
Bam(!), I think, I first need a tiny shot now ;-) and let that info sink in ...
Cheers Jörg
On 5/31/2018 0:10 AM, Rushforth, Kevin wrote:
I would like to propose the following Draft JEP [1] for discussion.
JDK-8200758: Packaging Tool
This is intended as a JDK-scope replacement for the existing javapackager tool that ships with Oracle JDK 10 (and earlier Oracle JDK releases), and was delivered as part of the JavaFX build. The javapackager tool has been removed from Oracle JDK 11 along with the removal of JavaFX.
Comments on this JEP are welcome. It is currently not targeted for a specific release, but we are aiming for JDK 12.
-- Kevin
An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone http://hg.openjdk.java.net/jdk/sandbox cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch [2] https://bugs.openjdk.java.net/browse/JDK-8200758 On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
I've just taking a look at the patch, i don't see how this can be integrated soon, the code is consistently inconsistent as one of my colleague would say, even the coding conventions are not respected. i believe that's it's because the code have been written first in Java 6 an without refactoring was moved to use Java 7, 8, 9, 10 and 11. The I/O code still using java.io.File for some parts, no try-with-resources so most of the try/finally are not safe, a lot of code like new BufferedWriter(new FileWriter(file)) instead of Files.newBufferedWriter, etc. The code should use the package java.nio.file, and not the old java.io, most of the code try to manage the exception right were they appear instead of propagating them so there are too many try/catch, a lot of catch are ignored which is a code smell, some codes use the internal logger (jdk.packager.internal.Log), but a lot of codes doesn't, for the collection code, there is a lot of copy of data small structures (which suggest that published collections are not immutable), there are dubious @SuppressWarnings("unchecked"), some or them are due to the fact that the code use Class as a type token instead of using lambdas, Stream are not used when they should (to avoid multiple copy between data structures) and streams that need to be closed are not (the result of Files.list by example), there are usual "don't do that in Java" like a loop using an integer index to traverse a List without knowing if it's a random access list or not, there is a lot of nullchecks instead of using Optional, a lot of code initialize local variables to null which is a code smell (and a side effect of having a lot of try/catch but not only), constructors should not do work, just initialization, use static factory method instead (so you will not have to debug half constructed objects), the code uses BigIntegers to parse a bundle version, just in case, the code uses an AtomicReference as a box that a lambda can mutate, instead of wrapping the exception into a runtime and unwrapping it at call site, The code of jdk.packager.internal.IOUtils should be updated to use methods of the JDK 11 and methods like readFully should be replaced by the JDK's one. listOfPathToString and setOfStringToString are just WTF, like in getRedistributableModules(), where the variable stream is an Optional, A class like Platform should be used everywhere to do platform specific stuff, a lot of code still use String matching (the version parsing should use System.Version). All the argument parsing should be delegated to JOpt (the one integrated with the JDK), so it will be consistent with the other JDK tools, There is a UnsupportedPlatformException but a Platform can be UNKOWN ?? I will stop here, my point is that there is a lot of cleaning that should appear before the code is integrated into the JDK and given the size of the code, i wonder if it's not better to start an OpenJDK project for it and iterate on the code before trying to include it in the JDK. For me, the code is too big to use the jdk/sandbox. regards, Rémi ----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Cc: "Alexey Semenyuk" <alexey.Semenyuk@oracle.com>, "Andy Herrick" <andy.herrick@oracle.com> Envoyé: Vendredi 6 Juillet 2018 22:14:29 Objet: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows:
hg clone http://hg.openjdk.java.net/jdk/sandbox cd ./sandbox hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply.
-- Kevin
[1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch [2] https://bugs.openjdk.java.net/browse/JDK-8200758
On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
Hi Remy, Thank you for taking a look. Yes, the javapackager code that forms the basis for the jpackager prototype was initially developed on older JDKs and evolved from there. I'm sure the improvements you suggest are all good ones, and it doesn't seem like it would be too hard to address the most important of them, especially the try-with-resources or anything else that would affect the robustness of the tool. As long as we do address the robustness issues, I think it is more important to get the feature set right, and make sure that the public interfaces -- the command line options and ToolProvider interface -- are clean. I don't see the need to rewrite the tool or take an extra couple of months to modernize all of the implementation to use JDK 11 APIs everywhere. Also, I don't agree that jpackager is too large for jdk/sandbox or that it needs it own project. The jdk/sandbox is perfect for new modules / new tools that don't impact other parts of the JDK. -- Kevin On 7/6/2018 3:07 PM, Remi Forax wrote:
I've just taking a look at the patch, i don't see how this can be integrated soon, the code is consistently inconsistent as one of my colleague would say, even the coding conventions are not respected. i believe that's it's because the code have been written first in Java 6 an without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so most of the try/finally are not safe, a lot of code like new BufferedWriter(new FileWriter(file)) instead of Files.newBufferedWriter, etc. The code should use the package java.nio.file, and not the old java.io, most of the code try to manage the exception right were they appear instead of propagating them so there are too many try/catch, a lot of catch are ignored which is a code smell, some codes use the internal logger (jdk.packager.internal.Log), but a lot of codes doesn't, for the collection code, there is a lot of copy of data small structures (which suggest that published collections are not immutable), there are dubious @SuppressWarnings("unchecked"), some or them are due to the fact that the code use Class as a type token instead of using lambdas, Stream are not used when they should (to avoid multiple copy between data structures) and streams that need to be closed are not (the result of Files.list by example), there are usual "don't do that in Java" like a loop using an integer index to traverse a List without knowing if it's a random access list or not, there is a lot of nullchecks instead of using Optional, a lot of code initialize local variables to null which is a code smell (and a side effect of having a lot of try/catch but not only), constructors should not do work, just initialization, use static factory method instead (so you will not have to debug half constructed objects), the code uses BigIntegers to parse a bundle version, just in case, the code uses an AtomicReference as a box that a lambda can mutate, instead of wrapping the exception into a runtime and unwrapping it at call site, The code of jdk.packager.internal.IOUtils should be updated to use methods of the JDK 11 and methods like readFully should be replaced by the JDK's one. listOfPathToString and setOfStringToString are just WTF, like in getRedistributableModules(), where the variable stream is an Optional, A class like Platform should be used everywhere to do platform specific stuff, a lot of code still use String matching (the version parsing should use System.Version). All the argument parsing should be delegated to JOpt (the one integrated with the JDK), so it will be consistent with the other JDK tools, There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
I will stop here, my point is that there is a lot of cleaning that should appear before the code is integrated into the JDK and given the size of the code, i wonder if it's not better to start an OpenJDK project for it and iterate on the code before trying to include it in the JDK. For me, the code is too big to use the jdk/sandbox.
regards, Rémi
----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Cc: "Alexey Semenyuk" <alexey.Semenyuk@oracle.com>, "Andy Herrick" <andy.herrick@oracle.com> Envoyé: Vendredi 6 Juillet 2018 22:14:29 Objet: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows:
hg clone http://hg.openjdk.java.net/jdk/sandbox cd ./sandbox hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply.
-- Kevin
[1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch [2] https://bugs.openjdk.java.net/browse/JDK-8200758
On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth@oracle.com> À: "Remi Forax" <forax@univ-mlv.fr> Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "Alexey Semenyuk" <alexey.Semenyuk@oracle.com>, "Andy Herrick" <andy.herrick@oracle.com> Envoyé: Samedi 7 Juillet 2018 15:47:01 Objet: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
Hi Remy,
Thank you for taking a look.
Yes, the javapackager code that forms the basis for the jpackager prototype was initially developed on older JDKs and evolved from there. I'm sure the improvements you suggest are all good ones, and it doesn't seem like it would be too hard to address the most important of them, especially the try-with-resources or anything else that would affect the robustness of the tool. As long as we do address the robustness issues, I think it is more important to get the feature set right, and make sure that the public interfaces -- the command line options and ToolProvider interface -- are clean. I don't see the need to rewrite the tool or take an extra couple of months to modernize all of the implementation to use JDK 11 APIs everywhere.
Also, I don't agree that jpackager is too large for jdk/sandbox or that it needs it own project. The jdk/sandbox is perfect for new modules / new tools that don't impact other parts of the JDK.
-- Kevin
Hi Kevin, like you, i don't think that a full rewrite is necessary, as you said having the right public 'interfaces' is enough, but reducing the size the duplicated code (with the JDK and internally) is as important in my opinion. For the first point, it means that jpackager should use jopt for the argument parsing (to be fully compatible with the GNU style of options). For the second point, it means to change a lot of code that may break because it's less mechanical than introducing try-with-resources. regards, Rémi
On 7/6/2018 3:07 PM, Remi Forax wrote:
I've just taking a look at the patch, i don't see how this can be integrated soon, the code is consistently inconsistent as one of my colleague would say, even the coding conventions are not respected. i believe that's it's because the code have been written first in Java 6 an without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so most of the try/finally are not safe, a lot of code like new BufferedWriter(new FileWriter(file)) instead of Files.newBufferedWriter, etc. The code should use the package java.nio.file, and not the old java.io, most of the code try to manage the exception right were they appear instead of propagating them so there are too many try/catch, a lot of catch are ignored which is a code smell, some codes use the internal logger (jdk.packager.internal.Log), but a lot of codes doesn't, for the collection code, there is a lot of copy of data small structures (which suggest that published collections are not immutable), there are dubious @SuppressWarnings("unchecked"), some or them are due to the fact that the code use Class as a type token instead of using lambdas, Stream are not used when they should (to avoid multiple copy between data structures) and streams that need to be closed are not (the result of Files.list by example), there are usual "don't do that in Java" like a loop using an integer index to traverse a List without knowing if it's a random access list or not, there is a lot of nullchecks instead of using Optional, a lot of code initialize local variables to null which is a code smell (and a side effect of having a lot of try/catch but not only), constructors should not do work, just initialization, use static factory method instead (so you will not have to debug half constructed objects), the code uses BigIntegers to parse a bundle version, just in case, the code uses an AtomicReference as a box that a lambda can mutate, instead of wrapping the exception into a runtime and unwrapping it at call site, The code of jdk.packager.internal.IOUtils should be updated to use methods of the JDK 11 and methods like readFully should be replaced by the JDK's one. listOfPathToString and setOfStringToString are just WTF, like in getRedistributableModules(), where the variable stream is an Optional, A class like Platform should be used everywhere to do platform specific stuff, a lot of code still use String matching (the version parsing should use System.Version). All the argument parsing should be delegated to JOpt (the one integrated with the JDK), so it will be consistent with the other JDK tools, There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
I will stop here, my point is that there is a lot of cleaning that should appear before the code is integrated into the JDK and given the size of the code, i wonder if it's not better to start an OpenJDK project for it and iterate on the code before trying to include it in the JDK. For me, the code is too big to use the jdk/sandbox.
regards, Rémi
----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Cc: "Alexey Semenyuk" <alexey.Semenyuk@oracle.com>, "Andy Herrick" <andy.herrick@oracle.com> Envoyé: Vendredi 6 Juillet 2018 22:14:29 Objet: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows:
hg clone http://hg.openjdk.java.net/jdk/sandbox cd ./sandbox hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply.
-- Kevin
[1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch [2] https://bugs.openjdk.java.net/browse/JDK-8200758
On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
For the first point, it means that jpackager should use jopt for the argument parsing (to be fully compatible with the GNU style of options). For the second point, it means to change a lot of code that may break because it's less mechanical than introducing try-with-resources.
This seems quite a reasonable suggestion. Thanks. -- Kevin On 7/7/2018 7:10 AM, forax@univ-mlv.fr wrote:
----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth@oracle.com> À: "Remi Forax" <forax@univ-mlv.fr> Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>, "Alexey Semenyuk" <alexey.Semenyuk@oracle.com>, "Andy Herrick" <andy.herrick@oracle.com> Envoyé: Samedi 7 Juillet 2018 15:47:01 Objet: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] Hi Remy,
Thank you for taking a look.
Yes, the javapackager code that forms the basis for the jpackager prototype was initially developed on older JDKs and evolved from there. I'm sure the improvements you suggest are all good ones, and it doesn't seem like it would be too hard to address the most important of them, especially the try-with-resources or anything else that would affect the robustness of the tool. As long as we do address the robustness issues, I think it is more important to get the feature set right, and make sure that the public interfaces -- the command line options and ToolProvider interface -- are clean. I don't see the need to rewrite the tool or take an extra couple of months to modernize all of the implementation to use JDK 11 APIs everywhere.
Also, I don't agree that jpackager is too large for jdk/sandbox or that it needs it own project. The jdk/sandbox is perfect for new modules / new tools that don't impact other parts of the JDK.
-- Kevin Hi Kevin, like you, i don't think that a full rewrite is necessary, as you said having the right public 'interfaces' is enough, but reducing the size the duplicated code (with the JDK and internally) is as important in my opinion.
For the first point, it means that jpackager should use jopt for the argument parsing (to be fully compatible with the GNU style of options). For the second point, it means to change a lot of code that may break because it's less mechanical than introducing try-with-resources.
regards, Rémi
On 7/6/2018 3:07 PM, Remi Forax wrote:
I've just taking a look at the patch, i don't see how this can be integrated soon, the code is consistently inconsistent as one of my colleague would say, even the coding conventions are not respected. i believe that's it's because the code have been written first in Java 6 an without refactoring was moved to use Java 7, 8, 9, 10 and 11.
The I/O code still using java.io.File for some parts, no try-with-resources so most of the try/finally are not safe, a lot of code like new BufferedWriter(new FileWriter(file)) instead of Files.newBufferedWriter, etc. The code should use the package java.nio.file, and not the old java.io, most of the code try to manage the exception right were they appear instead of propagating them so there are too many try/catch, a lot of catch are ignored which is a code smell, some codes use the internal logger (jdk.packager.internal.Log), but a lot of codes doesn't, for the collection code, there is a lot of copy of data small structures (which suggest that published collections are not immutable), there are dubious @SuppressWarnings("unchecked"), some or them are due to the fact that the code use Class as a type token instead of using lambdas, Stream are not used when they should (to avoid multiple copy between data structures) and streams that need to be closed are not (the result of Files.list by example), there are usual "don't do that in Java" like a loop using an integer index to traverse a List without knowing if it's a random access list or not, there is a lot of nullchecks instead of using Optional, a lot of code initialize local variables to null which is a code smell (and a side effect of having a lot of try/catch but not only), constructors should not do work, just initialization, use static factory method instead (so you will not have to debug half constructed objects), the code uses BigIntegers to parse a bundle version, just in case, the code uses an AtomicReference as a box that a lambda can mutate, instead of wrapping the exception into a runtime and unwrapping it at call site, The code of jdk.packager.internal.IOUtils should be updated to use methods of the JDK 11 and methods like readFully should be replaced by the JDK's one. listOfPathToString and setOfStringToString are just WTF, like in getRedistributableModules(), where the variable stream is an Optional, A class like Platform should be used everywhere to do platform specific stuff, a lot of code still use String matching (the version parsing should use System.Version). All the argument parsing should be delegated to JOpt (the one integrated with the JDK), so it will be consistent with the other JDK tools, There is a UnsupportedPlatformException but a Platform can be UNKOWN ??
I will stop here, my point is that there is a lot of cleaning that should appear before the code is integrated into the JDK and given the size of the code, i wonder if it's not better to start an OpenJDK project for it and iterate on the code before trying to include it in the JDK. For me, the code is too big to use the jdk/sandbox.
regards, Rémi
----- Mail original -----
De: "Kevin Rushforth" <kevin.rushforth@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Cc: "Alexey Semenyuk" <alexey.Semenyuk@oracle.com>, "Andy Herrick" <andy.herrick@oracle.com> Envoyé: Vendredi 6 Juillet 2018 22:14:29 Objet: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows:
hg clone http://hg.openjdk.java.net/jdk/sandbox cd ./sandbox hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply.
-- Kevin
[1] http://hg.openjdk.java.net/jdk/sandbox/shortlog/JDK-8200758-branch [2] https://bugs.openjdk.java.net/browse/JDK-8200758
On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
Hi thanks for the update/info. I had a quick look at the changes. So, here some thoughts... As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.) What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place? Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all? Cheers Jörg -----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk <alexey.Semenyuk@oracle.com>; Andy Herrick <andy.herrick@oracle.com> Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows: hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_... cd ./sandbox hg update JDK-8200758-branch I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply. -- Kevin [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_... [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_b... On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
We will likely be able to deliver the .exe installer (with its dependency on Inno Setup). As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version. -- Kevin On 7/10/2018 4:35 AM, Buchberger, Joerg wrote:
Hi
thanks for the update/info. I had a quick look at the changes. So, here some thoughts...
As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.)
What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place?
Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all?
Cheers Jörg
-----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk <alexey.Semenyuk@oracle.com>; Andy Herrick <andy.herrick@oracle.com> Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows:
hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_... cd ./sandbox hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply.
-- Kevin
[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_... [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_b...
On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
Since support for services/daemons was already in javapackager, why does this have to be a stretch goal? Isn’t it mostly already done? I would like to see this in the initial implementation. It is something I’m currently using via javapackager. I’m still trying to figure out the best strategy from bridging the gap in Java 11 where suddenly no packager is available. My company has already decided to skip Java 9 and 10 altogether. Modules were too disruptive when they came in Java 9, which didn’t last long until Java 10. Given that Java 11 unbundled JavaFX, we decided not to bother trying to go to 10 just to have to re-jig everything for 11. Now 11 is missing key tools (javapackager) that we began to rely on, so we keep falling behind, unable to adopt the newer JDK/JRE because the cost is so high. The first time ever in the history of Java where we couldn’t just adapt the new JDK and tweak for minor issues if any. Migrating projects beyond Java 8 is a big pain. It would suck if Java 12 lacks what was available in Java 8. (Please excuse the rant.) Scott
On Jul 11, 2018, at 7:08 PM, Kevin Rushforth <kevin.rushforth@oracle.com> wrote:
We will likely be able to deliver the .exe installer (with its dependency on Inno Setup).
As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version.
-- Kevin
On 7/10/2018 4:35 AM, Buchberger, Joerg wrote: Hi
thanks for the update/info. I had a quick look at the changes. So, here some thoughts...
As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.)
What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place?
Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all?
Cheers Jörg
-----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk <alexey.Semenyuk@oracle.com>; Andy Herrick <andy.herrick@oracle.com> Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows:
hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_... cd ./sandbox hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply.
-- Kevin
[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_... [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_b...
On 6/27/2018 3:30 PM, Kevin Rushforth wrote: We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
Thanks for the insight. @Alexey: Then, how much work do you see in reactivating service bundler? Cheers Jörg -----Original Message----- From: Kevin Rushforth [mailto:kevin.rushforth@oracle.com] Sent: Donnerstag, 12. Juli 2018 01:09 To: Buchberger, Joerg <Joerg.Buchberger@pruftechnik.com>; core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk <alexey.Semenyuk@oracle.com>; Andy Herrick <andy.herrick@oracle.com> Subject: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool] We will likely be able to deliver the .exe installer (with its dependency on Inno Setup). As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version. -- Kevin On 7/10/2018 4:35 AM, Buchberger, Joerg wrote:
Hi
thanks for the update/info. I had a quick look at the changes. So, here some thoughts...
As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.)
What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place?
Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all?
Cheers Jörg
-----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk <alexey.Semenyuk@oracle.com>; Andy Herrick <andy.herrick@oracle.com> Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows:
hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_... cd ./sandbox hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply.
-- Kevin
[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.ne t_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch&d=DwIFaQ&c=uD3W7j5M6i1jD eSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK hVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=F-CqPAWlz-Cfb0k ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java .net_browse_JDK-2D8200758&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR W_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHq hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE dQ22wI9I&e=
On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
Jörg, I don't think it will be very much work to bring service bundler code from JFX packager into OpenJDK jpackager. Though I can't give you estimates on amount of work needed to be done for this at the moment. - Alexey On 7/23/2018 7:47 AM, Buchberger, Joerg wrote:
Thanks for the insight.
@Alexey: Then, how much work do you see in reactivating service bundler?
Cheers Jörg
-----Original Message----- From: Kevin Rushforth [mailto:kevin.rushforth@oracle.com] Sent: Donnerstag, 12. Juli 2018 01:09 To: Buchberger, Joerg <Joerg.Buchberger@pruftechnik.com>; core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk <alexey.Semenyuk@oracle.com>; Andy Herrick <andy.herrick@oracle.com> Subject: Re: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
We will likely be able to deliver the .exe installer (with its dependency on Inno Setup).
As for the service bundler, this will be a "nice to have" (a stretch goal) for this version, but isn't on the list of committed features. Alexsei might be able to comment further on how much work it would be to provide it, including documenting and testing it. This might give you, and other interested developers, a sense of how likely this is to make it for this version.
-- Kevin
On 7/10/2018 4:35 AM, Buchberger, Joerg wrote:
Hi
thanks for the update/info. I had a quick look at the changes. So, here some thoughts...
As described in JDK-8200758, and therefore expected, WinExeBundler has been removed in favor of putting focus on WinMsiBundler. (Although, I regret that decision - since my personal experience has been that InnoSetup based WinExeBundler has worked much better than wix based WinMsiBundler for our use cases - I can live with that.)
What is much more disturbing: WinServiceBundler has also been actively removed, although that was working fine together with both wix/msi and exe/iss. Why has service wrapping been removed as well, while the command line option for it is kept in place?
Is there any chance of service bundler coming back into scope of JDK-8200758 or coming back in at all?
Cheers Jörg
-----Original Message----- From: core-libs-dev [mailto:core-libs-dev-bounces@openjdk.java.net] On Behalf Of Kevin Rushforth Sent: Freitag, 6. Juli 2018 22:14 To: core-libs-dev@openjdk.java.net Cc: Alexey Semenyuk <alexey.Semenyuk@oracle.com>; Andy Herrick <andy.herrick@oracle.com> Subject: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]
An initial prototype of the jpackager tool has been pushed to a new 'JDK-8200758-branch' branch in the JDK sandbox [1]. If anyone is interested in taking a look, you can clone it as follows:
hg clone https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.net_jdk_... cd ./sandbox hg update JDK-8200758-branch
I plan to reply to the feedback already provided, and update the JEP [2] next week some time, but in the mean time if you have additional questions or comments, feel free to reply.
-- Kevin
[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.openjdk.java.ne t_jdk_sandbox_shortlog_JDK-2D8200758-2Dbranch&d=DwIFaQ&c=uD3W7j5M6i1jD eSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJK hVEy_Q&m=7aoiG26qKHqhAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=F-CqPAWlz-Cfb0k ae2FBEj4Ncd3ZBVu7BeOVY1AM-cA&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java .net_browse_JDK-2D8200758&d=DwIFaQ&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxR W_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=7aoiG26qKHq hAG4Ry-hOl_c8cZ2UdmcCtrya0JOnsgg&s=DFIAHtCR1o--KMLuBzurIzx5MDu67NgtUrE dQ22wI9I&e=
On 6/27/2018 3:30 PM, Kevin Rushforth wrote:
We're aiming to get this into JDK 12 early enough so that an EA build would be available around the time JDK 11 ships. That will allow you to take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in the next week or so so you can follow the development.
Also, thank you to those who have provided feedback. I'll reply to feedback soon and then incorporate it into an updated JEP.
-- Kevin
participants (7)
-
Alexey Semenyuk
-
Bernd Eckenfels
-
Buchberger, Joerg
-
forax＠univ-mlv.fr
-
Kevin Rushforth
-
Remi Forax
-
Scott Palmer