Draft JEP proposal: JDK-8200758: Packaging Tool

[Andy Herrick]

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 at 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
>>>>
>