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
