Draft JEP proposal: JDK-8200758: Packaging Tool
andy.herrick at oracle.com
Fri Jul 27 14:14:36 UTC 2018
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
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.
>>> On Jul 25, 2018, at 7:12 PM, Kevin Rushforth
>>> <kevin.rushforth at oracle.com> wrote:
>>> Thank you to all who provided feedback. I have updated the draft JEP
>>> , 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
>>>  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  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
>>>>  https://bugs.openjdk.java.net/browse/JDK-8200758
More information about the core-libs-dev