I'm concerned about the possible loss of the packager service, i.e. the
UserJvmOptionsService class and associated underlying machinery in the
jpackager.
Background:
I'm developing and maintaining an internal GUI tool for log analysis.
It reads, parses and aggregates data from many different
Right, I explicitly want to make the distinction between this and the “Multiple
launchers” stretch goal. I want to use the "multiple launchers” as well.
One way that I have used multiple launchers (on Linux, I don’t think I could
get it to work on Windows) is to have one launcher be a
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
;] On Behalf Of Scott Palmer
> Sent: Donnerstag, 26. Juli 2018 16:39
> To: Kevin Rushforth <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
>
> 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
-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
Of Scott Palmer
Sent: Donnerstag, 26. Juli 2018 16:39
To: Kevin Rushforth
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
"The input to jpackager includes: a Java ru
"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
be available as jlink plugin
- theming Installer
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: -974640832m Auftrag von
Gesendet: Donnerstag, Juli 26, 2018 2:12 AM
An: core-libs-dev@openjdk.java.net
Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Thank you
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,
- Mail original -
> De: "Bernd Eckenfels"
> À: "core-libs-dev"
> Envoyé: Jeudi 28 Juin 2018 22:47:23
> Objet: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
> You can add-modules from the JDK (only), so if you „—add-modules
> lang.base,JDK.j
Eckenfels
Cc: core-libs-dev
Betreff: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
no you can't,
--add-modules requires the module to have a module-info, being an automatic
module is not good enough.
regards,
Rémi
- Mail original -
> De: "Bernd Eckenfels"
> À
th.
>
> --
> https://Bernd.eckenfels.net
>
> From: core-libs-dev on behalf of
> Scott
> Palmer
> Sent: Thursday, June 28, 2018 2:32:13 PM
> To: Kevin Rushforth
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: Draft JEP proposal: JDK-8200758: Packagi
: core-libs-dev on behalf of Scott
Palmer
Sent: Thursday, June 28, 2018 2:32:13 PM
To: Kevin Rushforth
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
Doesn’t jlink require a *fully* modularized application? I.e. no non-module
dependencies
Doesn’t jlink require a *fully* modularized application? I.e. no non-module
dependencies.
The packaging tool should work with all runnable Java applications, not just
fully modularized ones.
Modularization seems to be a bit of an effort and is one of the main reasons my
application(s) are
-
From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com]
Sent: Donnerstag, 28. Juni 2018 00:31
To: Buchberger, Joerg ;
core-libs-dev@openjdk.java.net
Subject: Re: Draft JEP proposal: JDK-8200758: Packaging Tool
We're aiming to get this into JDK 12 early enough so that an EA build would be
Hi Kevin,
Just a small request,
can you call it something like jbundler and not jpackager, because usually in
build tools the packager step is the step that create the jars, not the one
that bundle the whole application ?
regards,
Rémi
- Mail original -
> De: "Kevin Rushforth"
> À:
We're aiming to get this into JDK 12 early enough so that an EA build
would be available around the time JDK 11 ships. That will allow you to
take a jlinked image with JDK 11 and package it up using (the EA) jpackager.
We will create a development branch in the JDK sandbox [1] some time in
Thanks for the info! And thanks for the efforts. [no irony, no sarcasm - I
really mean it]
But, to sum up my comprehension...
anyone who placed their bets on javapackager, starting with last LTS Java 8
will be left in the rain with followup LTS Java 11, because their ain't neither
On 5/30/18 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
Hi Kevin,
Looks good, I assume as part of the work several existing javapackager bugs
will be swept up along the way? We use javapackager and are very happy
with what it gives us considering it is "free as in beer", but there are
some significant workarounds required for code signing, especially
On 31/05/2018 01:10, 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
21 matches
Mail list logo
