Re: Draft JEP proposal: JDK-8200758: Packaging Tool
I'm concerned about the possible loss of the packager service, i.e. the UserJvmOptionsService class and associated underlying machinery in the jpackager. Background: I'm developing and maintaining an internal GUI tool for log analysis. It reads, parses and aggregates data from many different kinds of logs from our production systems. The amount of memory needed to process all the data can vary quite a lot from run to run, so I've found it very convenient to utilise the UserJvmOptionsService to enable my users to set and manage the JVM settings of the JVM-bundled application created by javapackager. As far as I know, the javapackager, and the packager services, were omitted from JDK 11. While I can still use the javapackager of JDK 10 to package a JDK 11 application, I don't see how I could use the packager services, since they are not present. neither in JDK 11 nor in openjfx 11. I would like to suggest the UserJvmOptionsService, or equivalent, be retained in the successor tool, jpackager. Best regards, /Lennart Börjeson
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Right, I explicitly want to make the distinction between this and the “Multiple launchers” stretch goal. I want to use the "multiple launchers” as well. One way that I have used multiple launchers (on Linux, I don’t think I could get it to work on Windows) is to have one launcher be a service/daemon and a second launcher be a configuration utility for the service. I have some cases where multiple services are installed, each can be independent, but normally they are part of several different product suites. The total product itself can share a JRE, that’s where I want the option to specify a private, shared JRE. The JRE often makes up the majority of the application’s size. This can come down with jlink of course, but because of the nature of our product - with many plugins that are installed after the fact, we need a full JRE as we can’t anticipate what modules the plugins will need. Scott > On Jul 27, 2018, at 10:14 AM, Andy Herrick wrote: > > I don't see why this isn't feasible, and will file such an enhancement > request, but should be possible to deliver a suite of apps in one bundle. > This is the third 'stretch goal' : "Multiple launchers (enables a suite of > applications to be bundled in a single self-contained application package)" > > /Andy > > > On 7/27/2018 9:13 AM, Kevin Rushforth wrote: >> > Will it be possible to NOT include the JRE, but specify instead a >> > pre-existing location for the JRE? >> >> This does seem like an interesting use case. As you say, it is similar in >> many ways to both the Multiple Launchers and system JRE, but not quite the >> same as either. The mechanism to manage and locate these shared-but-private >> JREs seems like the most challenging part. We can add it to the "if there is >> time" list of features, but I don't know how feasible it is for the first >> version. Andy or Alexey can comment as to whether the current prototype has >> done anything that would make this difficult. >> >> -- Kevin >> >> >> On 7/26/2018 7:38 AM, Scott Palmer wrote: >>> "The input to jpackager includes: a Java runtime image, and a Java >>> application in one of several formats..." >>> >>> Will it be possible to NOT include the JRE, but specify instead a >>> pre-existing location for the JRE? >>> >>> As an example use-case consider an office productivity suite where there >>> are separate installers for a word processor and a spreadsheet application. >>> These applications are independent and can be installed in any combination >>> (word processor only, both, spreadsheet only). However they are part of >>> the same versioned application suite and have been developed and tested >>> with a particular JRE. Only a single JRE needs to be installed. The >>> applications can share it. This is not the same as using a system-wide JRE >>> (is that even supported for Java 11 and beyond?). But a shared private JRE >>> controlled by the application developer. >>> >>> This is similar but not the same as the proposed "Multiple launchers" >>> feature (if time allows), as the shared JRE could be used by different >>> software packages. >>> >>> In many cases the JRE is a very large part of the software installation, >>> both in terms of the size of the distributed installer package and the >>> storage requirements of the installed application. JRE sharing can help >>> with this. >>> >>> I'm thinking that eventually we could get to the point where developers >>> could treat the JRE as a versioned dependency, also covering the case of >>> customized JRE images. I don't propose that this jpackager tool be >>> involved in creating or distributing such JRE images, only that it supports >>> running applications using a pre-installed JRE where the location can be >>> determined at installer build time or perhaps install time. >>> >>> This was possible with the javapackager tool. >>> >>> Scott >>> On Jul 25, 2018, at 7:12 PM, Kevin Rushforth wrote: Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth 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
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
I don't see why this isn't feasible, and will file such an enhancement request, but should be possible to deliver a suite of apps in one bundle. This is the third 'stretch goal' : "Multiple launchers (enables a suite of applications to be bundled in a single self-contained application package)" /Andy On 7/27/2018 9:13 AM, Kevin Rushforth wrote: > Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? This does seem like an interesting use case. As you say, it is similar in many ways to both the Multiple Launchers and system JRE, but not quite the same as either. The mechanism to manage and locate these shared-but-private JREs seems like the most challenging part. We can add it to the "if there is time" list of features, but I don't know how feasible it is for the first version. Andy or Alexey can comment as to whether the current prototype has done anything that would make this difficult. -- Kevin On 7/26/2018 7:38 AM, Scott Palmer wrote: "The input to jpackager includes: a Java runtime image, and a Java application in one of several formats..." Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? As an example use-case consider an office productivity suite where there are separate installers for a word processor and a spreadsheet application. These applications are independent and can be installed in any combination (word processor only, both, spreadsheet only). However they are part of the same versioned application suite and have been developed and tested with a particular JRE. Only a single JRE needs to be installed. The applications can share it. This is not the same as using a system-wide JRE (is that even supported for Java 11 and beyond?). But a shared private JRE controlled by the application developer. This is similar but not the same as the proposed "Multiple launchers" feature (if time allows), as the shared JRE could be used by different software packages. In many cases the JRE is a very large part of the software installation, both in terms of the size of the distributed installer package and the storage requirements of the installed application. JRE sharing can help with this. I'm thinking that eventually we could get to the point where developers could treat the JRE as a versioned dependency, also covering the case of customized JRE images. I don't propose that this jpackager tool be involved in creating or distributing such JRE images, only that it supports running applications using a pre-installed JRE where the location can be determined at installer build time or perhaps install time. This was possible with the javapackager tool. Scott On Jul 25, 2018, at 7:12 PM, Kevin Rushforth wrote: Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth 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://bugs.openjdk.java.net/browse/JDK-8200758
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
With the existing javapackager there are some limitations. On Windows I only use it to go as far as creating the application image. I then run the WiX commands in my Gradle build script to finish creating an installer that has an added custom component used to tweak the .cfg file. (Creating just the application image is something that should still be possible with the new tool.) On Linux the full install package can be built directly with javapackager. The idea is to set the packager to use the system JRE. This creates an application image with the .cfg file configured with no JRE path ("app.runtime=“) and no JRE files bundled. For Linux builds, I customize the .spec file used by the packager (in verbose mode the packager tells you where it put the generated file .spec file so you can customize it). I add a simple command to modify the application’s .cfg file with a simple search/replace of the app.runtime= line. E.g. for MyApplication which installs in /opt: # Tweak .cfg to point to JRE if it is not already specified. E.g.: change “app.runtime=" to "app.runtime=/usr/java/latest" sed -e 's/^app\.runtime=$/app\.runtime=\/usr\/java\/latest/' %{_sourcedir}/MyApplication/app/MyApplication.cfg > %{buildroot}/opt/MyApplication/app/MyApplication.cfg On Windows, I take advantage of the fact that the .cfg file follows the convention of a Windows .ini file and MSI/WiX has a mechanism to add or modify .ini file entries. This WiX code added to some component, where the jre64FolderId is refers to the install location of the private JRE, and appDirId refers the the ‘app’ sub-folder of the application image. My Gradle build script sets some of these variables: In both cases I use a separate module for the private JRE that can be shared among other applications. The JRE installs to a common company folder in a versioned sub-folder so we can have multiple private JREs as we migrate products to newer JREs, but only ever one copy of any given version of the JRE. My concern with the new tool is that removal of support for a “system JRE” would make it impossible to build a package that doesn't contain a JRE, bloating the sizes of both the installer and installed image footprint (since applications can’t share a common JRE easily). Having the applications run on the same JRE may also have benefits related to class data sharing. Scott > On Jul 27, 2018, at 7:59 AM, Buchberger, Joerg > wrote: > > Thanks for the info - I was not aware of these possibilities in javapackager. > > @Kevin: just fyi, this would be also a very useful feature for the company I > work for and for our projects > > @Scott: please, let me know, how to achieve this with javapackager > > Cheers > Jörg > > > -Original Message- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net > <mailto:core-libs-dev-boun...@openjdk.java.net>] On Behalf Of Scott Palmer > Sent: Donnerstag, 26. Juli 2018 16:39 > To: Kevin Rushforth <mailto:kevin.rushfo...@oracle.com>> > Cc: core-libs-dev@openjdk.java.net <mailto:core-libs-dev@openjdk.java.net> > Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool > > "The input to jpackager includes: a Java runtime image, and a Java > application in one of several formats..." > > Will it be possible to NOT include the JRE, but specify instead a > pre-existing location for the JRE? > > > This was possible with the javapackager tool. > > Scott
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
> Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? This does seem like an interesting use case. As you say, it is similar in many ways to both the Multiple Launchers and system JRE, but not quite the same as either. The mechanism to manage and locate these shared-but-private JREs seems like the most challenging part. We can add it to the "if there is time" list of features, but I don't know how feasible it is for the first version. Andy or Alexey can comment as to whether the current prototype has done anything that would make this difficult. -- Kevin On 7/26/2018 7:38 AM, Scott Palmer wrote: "The input to jpackager includes: a Java runtime image, and a Java application in one of several formats..." Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? As an example use-case consider an office productivity suite where there are separate installers for a word processor and a spreadsheet application. These applications are independent and can be installed in any combination (word processor only, both, spreadsheet only). However they are part of the same versioned application suite and have been developed and tested with a particular JRE. Only a single JRE needs to be installed. The applications can share it. This is not the same as using a system-wide JRE (is that even supported for Java 11 and beyond?). But a shared private JRE controlled by the application developer. This is similar but not the same as the proposed "Multiple launchers" feature (if time allows), as the shared JRE could be used by different software packages. In many cases the JRE is a very large part of the software installation, both in terms of the size of the distributed installer package and the storage requirements of the installed application. JRE sharing can help with this. I'm thinking that eventually we could get to the point where developers could treat the JRE as a versioned dependency, also covering the case of customized JRE images. I don't propose that this jpackager tool be involved in creating or distributing such JRE images, only that it supports running applications using a pre-installed JRE where the location can be determined at installer build time or perhaps install time. This was possible with the javapackager tool. Scott On Jul 25, 2018, at 7:12 PM, Kevin Rushforth wrote: Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth 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://bugs.openjdk.java.net/browse/JDK-8200758
RE: Draft JEP proposal: JDK-8200758: Packaging Tool
Thanks for the info - I was not aware of these possibilities in javapackager. @Kevin: just fyi, this would be also a very useful feature for the company I work for and for our projects @Scott: please, let me know, how to achieve this with javapackager Cheers Jörg -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Scott Palmer Sent: Donnerstag, 26. Juli 2018 16:39 To: Kevin Rushforth Cc: core-libs-dev@openjdk.java.net Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool "The input to jpackager includes: a Java runtime image, and a Java application in one of several formats..." Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? As an example use-case consider an office productivity suite where there are separate installers for a word processor and a spreadsheet application. These applications are independent and can be installed in any combination (word processor only, both, spreadsheet only). However they are part of the same versioned application suite and have been developed and tested with a particular JRE. Only a single JRE needs to be installed. The applications can share it. This is not the same as using a system-wide JRE (is that even supported for Java 11 and beyond?). But a shared private JRE controlled by the application developer. This is similar but not the same as the proposed "Multiple launchers" feature (if time allows), as the shared JRE could be used by different software packages. In many cases the JRE is a very large part of the software installation, both in terms of the size of the distributed installer package and the storage requirements of the installed application. JRE sharing can help with this. I'm thinking that eventually we could get to the point where developers could treat the JRE as a versioned dependency, also covering the case of customized JRE images. I don't propose that this jpackager tool be involved in creating or distributing such JRE images, only that it supports running applications using a pre-installed JRE where the location can be determined at installer build time or perhaps install time. This was possible with the javapackager tool. Scott > On Jul 25, 2018, at 7:12 PM, Kevin Rushforth > wrote: > > Thank you to all who provided feedback. I have updated the draft JEP [1], and > I think I have incorporated most of the feedback I received. Specifically, I > have reorganized and reworded a few things for clarity, added '.exe' and > '.app in a .dmg' native package format to the list of features, and added the > service bundler (daemon) feature to the "if we have time" list (at the top of > that list). > > Please let me know if I missed an important point. I hope to submit this JEP > in the next week or two. > > -- Kevin > > [1] > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8200758&d=DwIFAg&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=KlUfgj63empIAez-vk164MMdqh0UIH4raiiK6AKkZmE&s=_R35pRHxi2Ndq3uYY8hHyYuFLWB2IGONK0xIZ_D7GfU&e= > > > On 5/30/2018 5:10 PM, Kevin Rushforth 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.java.net_browse_JDK-2D8200758&d=DwIFAg&c=uD3W7j5M6i1jDeSybgeVwm110GaiTFmxRW_bPSUkfEI&r=iA565f2Lw9W7rluKs5jkpPnslpNKVsvq0dJJKhVEy_Q&m=KlUfgj63empIAez-vk164MMdqh0UIH4raiiK6AKkZmE&s=_R35pRHxi2Ndq3uYY8hHyYuFLWB2IGONK0xIZ_D7GfU&e= >> >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
"The input to jpackager includes: a Java runtime image, and a Java application in one of several formats..." Will it be possible to NOT include the JRE, but specify instead a pre-existing location for the JRE? As an example use-case consider an office productivity suite where there are separate installers for a word processor and a spreadsheet application. These applications are independent and can be installed in any combination (word processor only, both, spreadsheet only). However they are part of the same versioned application suite and have been developed and tested with a particular JRE. Only a single JRE needs to be installed. The applications can share it. This is not the same as using a system-wide JRE (is that even supported for Java 11 and beyond?). But a shared private JRE controlled by the application developer. This is similar but not the same as the proposed "Multiple launchers" feature (if time allows), as the shared JRE could be used by different software packages. In many cases the JRE is a very large part of the software installation, both in terms of the size of the distributed installer package and the storage requirements of the installed application. JRE sharing can help with this. I'm thinking that eventually we could get to the point where developers could treat the JRE as a versioned dependency, also covering the case of customized JRE images. I don't propose that this jpackager tool be involved in creating or distributing such JRE images, only that it supports running applications using a pre-installed JRE where the location can be determined at installer build time or perhaps install time. This was possible with the javapackager tool. Scott > On Jul 25, 2018, at 7:12 PM, Kevin Rushforth > wrote: > > Thank you to all who provided feedback. I have updated the draft JEP [1], and > I think I have incorporated most of the feedback I received. Specifically, I > have reorganized and reworded a few things for clarity, added '.exe' and > '.app in a .dmg' native package format to the list of features, and added the > service bundler (daemon) feature to the "if we have time" list (at the top of > that list). > > Please let me know if I missed an important point. I hope to submit this JEP > in the next week or two. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758 > > > On 5/30/2018 5:10 PM, Kevin Rushforth 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://bugs.openjdk.java.net/browse/JDK-8200758 >> >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Hello, Will there be: - support for displaying and asking for acceptance of license text - asking for target directory (installing outside of programfiles) - starting optional post-Installation class - menu entries - user vs. System wide Installation (on windows) - the new launchers also be available as jlink plugin - theming Installer Gruss Bernd -- http://bernd.eckenfels.net Von: -974640832m Auftrag von Gesendet: Donnerstag, Juli 26, 2018 2:12 AM An: core-libs-dev@openjdk.java.net Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth 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://bugs.openjdk.java.net/browse/JDK-8200758 >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Thank you to all who provided feedback. I have updated the draft JEP [1], and I think I have incorporated most of the feedback I received. Specifically, I have reorganized and reworded a few things for clarity, added '.exe' and '.app in a .dmg' native package format to the list of features, and added the service bundler (daemon) feature to the "if we have time" list (at the top of that list). Please let me know if I missed an important point. I hope to submit this JEP in the next week or two. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8200758 On 5/30/2018 5:10 PM, Kevin Rushforth 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://bugs.openjdk.java.net/browse/JDK-8200758
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
- Mail original - > De: "Bernd Eckenfels" > À: "core-libs-dev" > 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 > -- > 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" >> À: "core-libs-dev" >> 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 on behalf of >> Scott >> Palmer >> 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 >>> 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 >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758
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. 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" > À: "core-libs-dev" > 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 on behalf of > Scott > Palmer > 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 >> 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 >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>
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" > À: "core-libs-dev" > 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 on behalf of > Scott > Palmer > 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 >> 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 >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>
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 on behalf of Scott Palmer 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 > 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 >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>> >
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 > 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 >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>> >
RE: Draft JEP proposal: JDK-8200758: Packaging Tool
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.rushfo...@oracle.com] Sent: Donnerstag, 28. Juni 2018 00:31 To: Buchberger, Joerg ; 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= >>
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Hi Kevin, Just a small request, can you call it something like jbundler and not jpackager, because usually in build tools the packager step is the step that create the jars, not the one that bundle the whole application ? regards, Rémi - Mail original - > De: "Kevin Rushforth" > À: "core-libs-dev" > Envoyé: Jeudi 31 Mai 2018 02:10:48 > Objet: Draft JEP proposal: JDK-8200758: Packaging Tool > 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://bugs.openjdk.java.net/browse/JDK-8200758
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://bugs.openjdk.java.net/browse/JDK-8200758
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 > > [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
On 5/30/18 5:10 PM, Kevin Rushforth 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://bugs.openjdk.java.net/browse/JDK-820075 Good to see this moving along. A couple of comments: I think the JEP may need to mention the layout of an application image and define what's supported and unsupported to make it clear for developers what should or should not depend on, for example, the location of the application launcher and user-editable configuration files etcs. javapackager strips the tool launchers from the run-time image and enables compression. Does jpackager do something similar? As the development moves along, it'd be useful to include some command-line examples and describe the content of the run-time image produced. As part of this JEP, we need to look at the difference of the native launcher created by jpackager and by jlink. jlink creates a native launcher for modular application and possibly share same mechanism in creating native launchers. Mandy
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Hi Kevin, Looks good, I assume as part of the work several existing javapackager bugs will be swept up along the way? We use javapackager and are very happy with what it gives us considering it is "free as in beer", but there are some significant workarounds required for code signing, especially on Mac OS X. Sign us (jClarity) up as early testers :-). Cheers, Martijn On 1 June 2018 at 08:53, Alan Bateman wrote: > On 31/05/2018 01:10, Kevin Rushforth 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://bugs.openjdk.java.net/browse/JDK-8200758 >> >> I read through the draft. > > The Goals and Non-Goals looks very reasonable. > > The Summary includes "self-contained Java Server ... applications" but the > JEP doesn't say too much about that part. Can we assume it can be started > and stopped with /etc/init.d or equivalent scripts, logs with the server > output etc? A general observation is that most of the issues around > end-user/GUI applications are clearly documented in the draft, the headless > application environment case less so. It makes me wonder if this JEP should > be split so that it initially focuses on the former. > > I think it would be useful if the JEP explained what an "application" is. > Is it a JAR file (with a Main-Class) that is deployed on the class path? > Can it be a module? What about modules and libraries that the application > uses. Users of javapackager might know these things but readers of the JEP > may not. > > The JEP mentions that JavaFX will be removed in JDK 11. I assume this > should be clarified so that it's clear it will no longer be shipped in > Oracle's JDK. It's a none issue for those using OpenJDK builds as the the > JavaFX modules were never bundled/imported by default. > > There are several references to "server JRE" that probably should be > clarified as this notion does not exist in OpenJDK. It may be that the JEP > just needs to clearer as to the modules that it links into the run-time > image. > > There are several references to "application launcher" and "native > launcher". At some point we need to work out some issues with jlink as it > it will need to generate native launchers too. The JEP could list it as an > issue as the development of this JEP will at least touch on some of this. > > The draft doesn't have a section on testing. If someone is building > OpenJDK then will they will require additional tools in the build > environment and can the tests be run without manual interaction? Also how > about a developer using the tool, will the generated native packages be > easy to un-install so they can easily test in a local environment? > > -Alan >
Re: Draft JEP proposal: JDK-8200758: Packaging Tool
On 31/05/2018 01:10, Kevin Rushforth 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://bugs.openjdk.java.net/browse/JDK-8200758 I read through the draft. The Goals and Non-Goals looks very reasonable. The Summary includes "self-contained Java Server ... applications" but the JEP doesn't say too much about that part. Can we assume it can be started and stopped with /etc/init.d or equivalent scripts, logs with the server output etc? A general observation is that most of the issues around end-user/GUI applications are clearly documented in the draft, the headless application environment case less so. It makes me wonder if this JEP should be split so that it initially focuses on the former. I think it would be useful if the JEP explained what an "application" is. Is it a JAR file (with a Main-Class) that is deployed on the class path? Can it be a module? What about modules and libraries that the application uses. Users of javapackager might know these things but readers of the JEP may not. The JEP mentions that JavaFX will be removed in JDK 11. I assume this should be clarified so that it's clear it will no longer be shipped in Oracle's JDK. It's a none issue for those using OpenJDK builds as the the JavaFX modules were never bundled/imported by default. There are several references to "server JRE" that probably should be clarified as this notion does not exist in OpenJDK. It may be that the JEP just needs to clearer as to the modules that it links into the run-time image. There are several references to "application launcher" and "native launcher". At some point we need to work out some issues with jlink as it it will need to generate native launchers too. The JEP could list it as an issue as the development of this JEP will at least touch on some of this. The draft doesn't have a section on testing. If someone is building OpenJDK then will they will require additional tools in the build environment and can the tests be run without manual interaction? Also how about a developer using the tool, will the generated native packages be easy to un-install so they can easily test in a local environment? -Alan