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
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
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
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 <Alan.Bateman@oracle.com> 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
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
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" <kevin.rushforth@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> 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
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
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
"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 <kevin.rushforth@oracle.com> 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
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-bounces@openjdk.java.net] On Behalf Of Scott Palmer Sent: Donnerstag, 26. Juli 2018 16:39 To: Kevin Rushforth <kevin.rushforth@oracle.com> 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 <kevin.rushforth@oracle.com> 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_b...
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_b...
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: <IniFile Id="AppCfg64" Action="addLine" Directory="$(var.appDirId)" Name="$(var.MyAppShortName).cfg" Section="Application" Key="app.runtime" Value="[$(var.jre64FolderId)]" /> 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 <Joerg.Buchberger@pruftechnik.com> 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-bounces@openjdk.java.net <mailto:core-libs-dev-bounces@openjdk.java.net>] On Behalf Of Scott Palmer Sent: Donnerstag, 26. Juli 2018 16:39 To: Kevin Rushforth <kevin.rushforth@oracle.com <mailto:kevin.rushforth@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?
<snip>
This was possible with the javapackager tool.
Scott
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 <kevin.rushforth@oracle.com> 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
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 <kevin.rushforth@oracle.com> 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
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 <andy.herrick@oracle.com> 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 <kevin.rushforth@oracle.com> 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
participants (9)
-
Alan Bateman
-
Andy Herrick
-
Bernd Eckenfels
-
Buchberger, Joerg
-
Kevin Rushforth
-
mandy chung
-
Martijn Verburg
-
Remi Forax
-
Scott Palmer