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.herr...@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.rushfo...@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 >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8200758 >>>>> >> >
