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.buchber...@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-boun...@openjdk.java.net
> <mailto:core-libs-dev-boun...@openjdk.java.net>] On Behalf Of Scott Palmer
> Sent: Donnerstag, 26. Juli 2018 16:39
> To: Kevin Rushforth <kevin.rushfo...@oracle.com
> <mailto:kevin.rushfo...@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
