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