Re: Javapackager 10 to bundle OpenJDK 11 runtime

doubt that will work. >>> >>> We are developing a replacement tool, jpackage [1], which will be part >>> of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later >>> as a Java runtime. You can download an early access of this tool on >>

Re: Javapackager 10 to bundle OpenJDK 11 runtime

ernatively, Gluon has a standalone > version of javapackager that will work with JDK 11. Johan Vos can > provide a pointer. > > -- Kevin > > [1] https://openjdk.java.net/jeps/343 > [2] http://jdk.java.net/jpackage/ > [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev >

Re: Javapackager 10 to bundle OpenJDK 11 runtime

libs-dev mailing list [3]. > Alternatively, Gluon has a standalone version of javapackager that will work > with JDK 11. Johan Vos can provide a pointer. > > -- Kevin > > [1] https://openjdk.java.net/jeps/343 > [2] http://jdk.java.net/jpackage/ > [3] http://mail.openjdk.java.net/mailman

Javapackager 10 to bundle OpenJDK 11 runtime

I understand the guidance for apps created with OpenJDK 11, is to use the javapackager from jdk 10. The old basedir parameter that could be used to direct the packager to use a specific runtime is no longer present. Is there any mechanism I’ve missed in order to have the packager from jdk10

Re: "javapackager" in no-mans-land?

removed from JDK 11. You will either need to find an alternative to > > Java Web Start or keep your application on JDK 8. Packaging your > > application with the JDK might be an alternative to Java Web Start. If > > so, the new jpackager tool could help you, in which case an inte

Re: "javapackager" in no-mans-land?

to Java Web Start. If > so, the new jpackager tool could help you, in which case an interim > solution would be to use use the javapackager, either the one from JDK > 10 or an unbundled javapackager, as suggested by others. > > > Any idea about auto update application in win

Re: "javapackager" in no-mans-land?

to Java Web Start or keep your application on JDK 8. Packaging your application with the JDK might be an alternative to Java Web Start. If so, the new jpackager tool could help you, in which case an interim solution would be to use use the javapackager, either the one from JDK 10 or an unbundled

Re: "javapackager" in no-mans-land?

gt; Any idea about auto update application in win(exe),mac,linux base application > ? > > > > > >> On Wed, Sep 19, 2018 at 11:54 AM Lennart Börjeson wrote: >> It was migrated, but removed... >> >> The recommended work-around is to use the ja

Re: "javapackager" in no-mans-land?

ved... > > The recommended work-around is to use the javapackager in OracleJDK 10 > when packing Java/OpenJfx 11 applications. > > That may or may not be practical depending on your build setup. Also, if > you’re currently using the UserJvmOptions services, these are also gone in > Java/

Re: "javapackager" in no-mans-land?

It was migrated, but removed... The recommended work-around is to use the javapackager in OracleJDK 10 when packing Java/OpenJfx 11 applications. That may or may not be practical depending on your build setup. Also, if you’re currently using the UserJvmOptions services, these are also gone

"javapackager" in no-mans-land?

I understand that along with JavaFX being removed from the Oracle JDK distribution in Java 11, the Oracle team will no longer release the `javapackager` tool. I also see there is a JEP discussing an eventual replacement, JEP-343 ( http://openjdk.java.net/jeps/343). Just to confirm, the tool

[12] Review request: 8203379: Remove javapackager sources from OpenJFX repo

Please review the following to remove the javapackager sources and build logic from the openjfx repo: https://bugs.openjdk.java.net/browse/JDK-8203379 http://cr.openjdk.java.net/~kcr/8203379/webrev.00/ See JBS for more information. -- Kevin

Re: javapackager usage

The javapackager tool, which was delivered as part of the Oracle JDK releases along with JavaFX in JDK 8 through JDK 10, has been removed from the JDK as of JDK 11. A JEP for a new packaging tool, jpackager, is being proposed and discussed on core-libs-dev [1]. -- Kevin [1] http

RE: javapackager usage

If this is the wrong mailing list for javapackager questions, I'd appreciate any hints regarding where to ask instead in case you happen to know. Thank you. -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Buchberger, Joerg Sent: Freitag

javapackager usage

Hi everyone Is this the right mailing list for all questions about javapackager? I tried to use javapackager for my spring-boot web application on Windows. So, naturally, it runs headless. Although, creating native image and running that exe was successful, there are some caveats I could

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

On 31.05.2018 02:11, Kevin Rushforth wrote: > I just sent an email to the core-libs-dev alias [1] proposing a new Packaging > Tool as a > replacement for javapackager. If you are interested in this JEP, you can > follow and participate in > the discussion there. > >

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

You are right. Here's an updated version of the app that take into account the time before Main::main() is invoked. import javafx.application.Application; import javafx.stage.Stage; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.layout.*; public class Main extends

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Hi! Just for the records: My test included the JVM startup time. Yours start counting in main() where the JVM is already up - and probably some of the classpath scanning already took place because of the inheritance from „javafx.application.Application“ . Your test shows „showing: 298 shown:

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Here's a more accurate (but still rough) timing application: import javafx.application.Application; import javafx.stage.Stage; import javafx.scene.Scene; import javafx.scene.control.*; import javafx.scene.layout.*; public class Main extends Application { private static long t1; private

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Yes, my only comment was that if we can get a window up using standard Java GUI frameworks fast enough, then the complexity of adding splashscreen support to the launcher isn't justified. Mario's example shows that is it 1-2 seconds to get a window up. That is a bit high. If it was under 1s then

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Sorry, perhaps it was I who misunderstood the debate.. On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus wrote: > Maybe I misunderstood the question but to my opinion the real question is > whether the new java packager has to provide the support for a splash > screen > or not. This has nothing to

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Hi! I’ve just test with this very small JavaFX Application: public class TstFx extends Application { @Override public void start(Stage primaryStage) throws Exception { Label root = new Label("test"); Scene scene = new Scene(root, 800, 600);

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Maybe I misunderstood the question but to my opinion the real question is whether the new java packager has to provide the support for a splash screen or not. This has nothing to do with the question whether applications should have a splash screen or not because if we find that todays Java is

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Nobody is arguing against splash screens. I’m simply suggesting that the JVM startup is not slow enough that we need special handling of this in native code. If Java can get a window displayed in under half a second there is no need for the added complexity to support a native splash screen in

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Hi, I agree with Johan and others, a splash screen is valuable and needed. Microsoft applications that run on Windows itself (think Word, Excel, etc), they have a splash screen, Intelllij has a splash screen (it's swing based AFAIK), etc.. If a Microsoft application running on its own operating

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

The problem is not the Java window, but the dependencies. If that window is created by a class that requires resolving other classes and somehow one of these classes take a long time to initialize, it will be slow. - Johan On Mon, Jun 4, 2018 at 12:53 PM Scott Palmer wrote: > If a Java window

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

If a Java window appears in less than half a second there is no point in adding the complexity of a native splash screen. Scott > On Jun 4, 2018, at 5:13 AM, Tom Schindl wrote: > > A splash screen has to be that instant that it IMHO makes no sense to > time how long it takes to get the JVM

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

A splash screen has to be that instant that it IMHO makes no sense to time how long it takes to get the JVM and JavaFX up and running because it can never be as instant as a splash has to show up. Tom On 04.06.18 01:06, Scott Palmer wrote: > Has anyone actually timed how long it takes to get a

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Has anyone actually timed how long it takes to get a Java window on screen? I don’t think the delay is long enough to bother with a splash screen these days. Scott > On Jun 3, 2018, at 4:22 AM, Tom Schindl wrote: > > That's why I requested that since a long time from the packager because > a

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

That's why I requested that since a long time from the packager because a splash has to be part of the native launcher created. The Eclipse-RCP-Launcher does exactly the right thing: * Show a static image (IIRC they use bmp) * Once the VM and UI-Toolkit is up replace that image with a window (SWT

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

A preloader/splash-screen will/should also hide the JVM startup time. Best regards, Mario > Am 03.06.2018 um 09:57 schrieb Tom Schindl : > > On 01.06.18 19:42, Johan Vos wrote: >> I'm not saying a preloader is really a requirement, but I know of a few >> applications that are using it and

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

On 01.06.18 19:42, Johan Vos wrote: > I'm not saying a preloader is really a requirement, but I know of a few > applications that are using it and benefiting from it. > > The preloader functionality is more than just a splash screen, and I see > this valuable for instance when static initializers

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

may take a lot of time. - Johan On Fri, Jun 1, 2018 at 5:56 PM Scott Palmer wrote: > > > > On Jun 1, 2018, at 5:01 AM, Tom Schindl > wrote: > > > > On 01.06.18 08:01, Michael Ennen wrote: > >> Re-familiarizing myself with what javapackager offers, it see

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

> On Jun 1, 2018, at 5:01 AM, Tom Schindl wrote: > > On 01.06.18 08:01, Michael Ennen wrote: >> Re-familiarizing myself with what javapackager offers, it seems the >> following JavaFX related >> features are present: >> >> 1.) The conversion of CSS to b

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

On 01.06.18 08:01, Michael Ennen wrote: > Re-familiarizing myself with what javapackager offers, it seems the > following JavaFX related > features are present: > > 1.) The conversion of CSS to binary CSS > 2.) The ability to specify a preloader > 3.) the ability to specify t

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Re-familiarizing myself with what javapackager offers, it seems the following JavaFX related features are present: 1.) The conversion of CSS to binary CSS 2.) The ability to specify a preloader 3.) the ability to specify the JavaFX Application class The first one seems like a bit of feature

Re: Draft JEP for new Packaging Tool (replacement for javapackager)

Tool as a replacement for javapackager. If you are interested in this JEP, you can follow and participate in the discussion there. -- Kevin [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html

Draft JEP for new Packaging Tool (replacement for javapackager)

I just sent an email to the core-libs-dev alias [1] proposing a new Packaging Tool as a replacement for javapackager. If you are interested in this JEP, you can follow and participate in the discussion there. -- Kevin [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503

[10] Review request: 8194488: "javapackager -singleton" is not working in linux

Alexander, Please review my changes for fixing the issue: "JDK-8194488: "javapackager -singleton" is not working in linux" JIRA: https://bugs.openjdk.java.net/browse/JDK-8194488 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8194488/webrev.00/ --Victor

[10] Review request: 8194040: "javapackager -help" doesn't display new option "-singleton"

Kevin, Please review my changes for fixing the issue: "8194040: "javapackager -help" doesn't display new option "-singleton"" JIRA: https://bugs.openjdk.java.net/browse/JDK-8194040 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8194040/webrev.00/ --Victor

[10] Review request: 8193353: javapackager is totally broken in "-createbss" mode

Kevin, Please review the changes about removing old code related with jfxrt.jar JIRA: https://bugs.openjdk.java.net/browse/JDK-8193353 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8193353/webrev.00/ --Victor

Re: javapackager: MacOSX: question about adding a file to the DMG outside of the app bundler

I have not tried it myself but this post http://crazyedy.com/tech/?p=535 claims that it is possible to add something like a readme after the DMG file has been created by making it writable. Am 06.12.17 um 16:58 schrieb Mani Sarkar: Hi, Has anyone worked out how to add a file like a README.txt

javapackager: MacOSX: question about adding a file to the DMG outside of the app bundler

Hi, Has anyone worked out how to add a file like a README.txt into the DMG volume such that its not bundled into the app bundler (.app file) but placed outside it so that it is visible when the DMG volume is mounted for installation? It sounds like a simple action but the usage or docs don't

Re: javapackager feedback and questions

en you specify systemWide=true on the MacOSX > in non-gui mode. Can you provide more details about that (like full cmd > line)? > Actually, if you want you can clone the repo: > http://hg.openjdk.java.net/openjfx/10-dev/rt/ > (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/) &

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

> On Dec 3, 2017, at 11:12 PM, victor.droz...@oracle.com wrote: > >> >> >> > writeEntry() is supposed to be used for the operations where we need to > create a directory and then do Files.copy(). I see no reason to avoid using > it here. Linux bundler is also implemented this way. > This

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

On 12/2/17 7:11 AM, Kevin Rushforth wrote: Michael Hall wrote: On Dec 2, 2017, at 8:31 AM, Kevin Rushforth > wrote: Michael Hall wrote: On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

> On Dec 2, 2017, at 9:11 AM, Kevin Rushforth > wrote: > > > > Michael Hall wrote: >> >> >>> On Dec 2, 2017, at 8:31 AM, Kevin Rushforth >> > wrote: >>> >>> >>> >>> Michael Hall wrote:

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

Michael Hall wrote: On Dec 2, 2017, at 8:31 AM, Kevin Rushforth > wrote: Michael Hall wrote: On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com wrote: Kevin, Please review the

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

> On Dec 2, 2017, at 8:31 AM, Kevin Rushforth > wrote: > > > > Michael Hall wrote: >> >> >>> On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com >>> wrote: >>> >>> Kevin, >>> >>> Please review the changes about copying

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

Michael Hall wrote: On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com wrote: Kevin, Please review the changes about copying classpath entries on Mac and Windows. JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033 Webrev:

Re: [10] Review request: 8179033: javapackager fails to create Mac Application Bundle

> On Dec 1, 2017, at 7:43 PM, victor.droz...@oracle.com wrote: > > Kevin, > > Please review the changes about copying classpath entries on Mac and Windows. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033 > Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ >

[10] Review request: 8179033: javapackager fails to create Mac Application Bundle

Kevin, Please review the changes about copying classpath entries on Mac and Windows. JIRA: https://bugs.openjdk.java.net/browse/JDK-8179033 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8179033/webrev.00/ --Victor

Re: javapackager feedback and questions

We are using the javapackager through the gradle/maven javafx plugin, to create: * Executable JAR: When we went from Swing to JavaFX the maven jar plugin could not create an executable JAR capable to start the JavaFX Application. * Native executable bundle: RPM (Linux), EXE (Windows), PKG (Mac

Re: javapackager feedback and questions

I’m using javapackager to generate native installers for several services and GUI applications. I would be using it for some command line tools as well, but it doesn’t yet support “console” applications on Windows. I.e. you can’t make javapackager with javapackager. I’ve filed an issue

Re: javapackager feedback and questions

Hi Victor, To answer your query about how javapackager can be made better, packr ( https://github.com/libgdx/packr) and FPM ( https://github.com/jordansissel/fpm) are two great examples in this space. If we can pool together some of the features from both, it would certainly draw attention

Re: javapackager feedback and questions

r. > > Related to this, we are soliciting input as to how people are using the > javapackager (see Victor's question below). > > So we'd love to hear how you and others are using it, and for what kind of > applications. > > — Kevin I was sort of waiting to see what came out of t

Re: javapackager feedback and questions

Hi Michael, We realized that the javapackger CLI JEP wasn't quite ready, and was out of scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later. Related to this, we are soliciting input as to how people are using the javapackager (see Victor's question below). So we'd

Re: javapackager feedback and questions

Hi Victor, I can answer the last Q. It's for two products, one is Censum our GC Log analyser (Java swing desktop app, yes they still exist! ;p) and the second is a stand alone Java 'daemon' for our APM SaaS tool (illuminate). jlink and javapackager is a powerful combination for us, so thanks

Re: javapackager feedback and questions

Thanks Victor for you response and invite. I'll get back with details for your query. Just for your info, I was referring to javapackager in the context of Java 9 built artifacts. On Thu, 30 Nov 2017 09:28 Michael Hall, <mik3h...@gmail.com> wrote: > > > On Nov 29, 2017, at 5:18

Re: javapackager feedback and questions

//hg.openjdk.java.net/openjfx/10-dev/rt/) > and help to improve javapackager. Or you can just create Enhancements for > deploy/packager, as it's not always clear what users expect. > Why was JEP 311 [1] Closed/Withdrawn? [1] http://openjdk.java.net/jeps/311

Re: javapackager feedback and questions

ani Sarkar: Hi all, First I hope I'm writing to the correct mailing list, if not please suggest where to write instead. Also if it is worth writing back as separate messages per issue or item, please do let me know. Some of my observations and feedback when using *javapackager*: *Positiv

Re: javapackager feedback and questions

. Can you provide more details about that (like full cmd line)? Actually, if you want you can clone the repo: http://hg.openjdk.java.net/openjfx/10-dev/rt/ (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/) and help to improve javapackager. Or you can just create Enhancements for deploy

javapackager feedback and questions

Hi all, First I hope I'm writing to the correct mailing list, if not please suggest where to write instead. Also if it is worth writing back as separate messages per issue or item, please do let me know. Some of my observations and feedback when using *javapackager*: *Positives* - .dmg and .msi

[10] Review request: 8191712: javapackager help output has a typo

Alexander, Please review my changes about fixing typos in javapackager help output and jdk/packager/builders/mac/MacAppImageBuilder. The fix also corrected the typo from JDK-8189339 JIRA: https://bugs.openjdk.java.net/browse/JDK-8191712 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK

[10] Review request: 8190758: javapackager fails to consider filesystem type

Kevin, Please review my changes about filesystem type for .dmg JIRA: https://bugs.openjdk.java.net/browse/JDK-8190758 Webrev:http://cr.openjdk.java.net/~vdrozdov/JDK-8190758/webrev.00/ --Victor

Review request: JDK-8185877: ,Fix X11 dependency in javapackager

Victor, Kevin, Please review changes to get rid of static dependency of JDK packager on X11. JIRA: https://bugs.openjdk.java.net/browse/JDK-8185877 Webrev: http://cr.openjdk.java.net/~asemenyuk/8185877/webrev.00/ Testing done: built and verified on Oracle Linux 7 and Ubuntu 16.04. - Alexey

[10] Review request: 8181291: Singleton for javapackager

Kevin, Chris, Please review my changes about Single Instance for Java Packager (compared to previous webrev, the code was modified according to CSR JDK-8181293) JIRA: https://bugs.openjdk.java.net/browse/JDK-8181291 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8175574/webrev.06/

JDK-8180368 javapackager and Maven Toolchains

Hi This issue [1] was given lower priority because "reproducing the bug requires intentionally setting JAVA_HOME to old JDK and using files from new one". However, I just want to point out that this is not some artificial construction: Maven Toolchains [2] allow to build projects with a JDK

Re: javapackager - partially self-contained apps in JDK 9

than building this JAR into the bundled app. >>> My thinking was that the connector might need to be updated in sync with >>> the database and I should not have to rebuild apps to do that. >>> >>> In JDK 9, the extension mechanism is gone. I have not found any way to >>>

Re: javapackager - partially self-contained apps in JDK 9

ilding this JAR into the bundled app. > My thinking was that the connector might need to be updated in sync with the > database and I should not have to rebuild apps to do that. > > In JDK 9, the extension mechanism is gone. I have not found any way to > achieve the equivalent

Re: javapackager - partially self-contained apps in JDK 9

ilding this JAR into the bundled app. > My thinking was that the connector might need to be updated in sync with the > database and I should not have to rebuild apps to do that. > > In JDK 9, the extension mechanism is gone. I have not found any way to > achieve the equivalent

[9] Review request: 8177451 javapackager -help prints help message of java -help

Kevin, Please review this fix to the javapackager.exe launcher. My last change, I thought I had tested it thoroughly but I made a mistake where I put one of the quotes but I also noticed some other problems. So it’s now launching as a modular application as well. This time I’ve carefully

Re: [9] Review request: JDK-8147781: Javapackager installer needs to cleanup temporary folders

Thanks for pointing out the problem. Currently, the directory is not removed regardless "-verbose" is specified or not. I think we can check if "-verbose" is specified, and if it is not, remove the temporary directory. New webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8147781/webrev.01/

Re: [9] Review request: JDK-8147781: Javapackager installer needs to cleanup temporary folders

That’s a good point Stefan. I hadn’t noticed the -verbose. Chris > On Feb 6, 2017, at 4:31 PM, Stefan Fuchs wrote: > > Hi, > > are you sure that there is a bug? > > The verbose paramter is explicitly documented to leave temporary files > around, as a starting point for

Re: [9] Review request: JDK-8147781: Javapackager installer needs to cleanup temporary folders

Hi, are you sure that there is a bug? The verbose paramter is explicitly documented to leave temporary files around, as a starting point for customization. Quote from https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html Verbose mode includes the

[9] Review request: JDK-8147781: Javapackager installer needs to cleanup temporary folders

Chris, Please review the changes about removing temporary files. JIRA: https://bugs.openjdk.java.net/browse/JDK-8147781 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8147781/webrev.00/ --Victor

[9] Review request: JDK-8154472: javapackager -createbss command is not working

Chris, Kevin, Please review the changes about exporting com.sun.javafx.css.parser to module jdk.packager. JIRA: https://bugs.openjdk.java.net/browse/JDK-8154472 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8154472/webrev.00/ --Victor

[9] Review request: JDK-8171352 javapackager throws "Exception: jdk.tools.jlink.plugin.PluginException: java.lang.IllegalArgumentException: No modules to add" when bundled with NormalJar

Kevin, Please review this minor change to build.gradle as a follow on to JDK-8170198. The location of the redistributable.list was incorrect and my testing didn’t catch it. JIRA: https://bugs.openjdk.java.net/browse/JDK-8171352 Webrev:

[9] Review request: JDK-8167388: value for key "LSApplicationCategoryType" is not set in Info.plist when trying to set through javapackager -BapplicationCategory=""

Chris, Please review the changes about ApplicationCategory (Info.plist) JIRA: https://bugs.openjdk.java.net/browse/JDK-8167388 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8167388/webrev.00/ --Victor

[9] Review request: JDK-8168407 javapackager throws "java.lang.ClassNotFoundException: testapp.util.Util" when bundle is built through ANT for unnamed module depending on named module scenario

Kevin, Please review this change to allow a non modular jar main app to use and bundle modular jars into the runtime image. JIRA: https://bugs.openjdk.java.net/browse/JDK-8168407 Webrev:

[9] Review request: JDK-8165794: javapackager throws "No application jars found" when "-srcfiles" is omitted in CLI

Chris, Please review the changes about "No application jars found" exception. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165794 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8165794/webrev.00/ --Victor

[9] Review request: JDK-8168501 javapackager system wide installation is failed when bundled through ANT in windows operating system

Chris, Please review the changes about system wide installation (bundled through ANT). JIRA: https://bugs.openjdk.java.net/browse/JDK-8168501 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8168501/webrev.00/ --Victor

Re: [9] Review request: JDK-8162693 javapackager returns null if com.oracle.tools.packager.windows.WinAppBundler called twice

Correct links: JIRA: https://bugs.openjdk.java.net/browse/JDK-8162693 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8162693/webrev.00/ --Victor Chris, Please review the changes about WinAppBundler. JIRA:

[9] Review request: JDK-8162693 javapackager returns null if com.oracle.tools.packager.windows.WinAppBundler called twice

Chris, Please review the changes about WinAppBundler. JIRA: https://bugs.openjdk.java.net/browse/JDK-8162693 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8162693/webrev.00/ --Victor

[9] Review request: JDK-8167973 Absolute path for module-path is not working when trying to execute javapackager from other drive in CLI

Kevin, Please review this change to fix the path separate for Windows. JIRA: https://bugs.openjdk.java.net/browse/JDK-8167973 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8167973/webrev.00/ Chris

[9] Review request: JDK-8166661 Remove "-outfile" as compulsary when bundling modules in javapackager

Kevin, Please review the following change to remove the required argument -outfile. JIRA: https://bugs.openjdk.java.net/browse/JDK-811 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-811/webrev.00/ Chris

Re: [9] Review Request: 8165414 javapackager throws NullPointerException in Windows Operating System for CLI

Kevin, did you see this one too? Chris > On Oct 5, 2016, at 8:11 AM, Chris Bensen wrote: > > Kevin, > > This resolves the NullPointerExceptions when packaging on Windows. > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8165414 >

[9] Review Request: 8165414 javapackager throws NullPointerException in Windows Operating System for CLI

Kevin, This resolves the NullPointerExceptions when packaging on Windows. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165414 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165414/webrev.00/

[9] Review Request: 8165548 javapackager -help shows --modulepath not --module-path

Kevin, Please review this simple string change. JIRA: https://bugs.openjdk.java.net/browse/JDK-8165548 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8165548/webrev.00/ Chris

[9] Review Request: 8163076 javapackager bundling fails due to issue in JAVA-API

Kevin, Please review this change to fix invoking the Java Packager through the Java Packager API. JIRA: https://bugs.openjdk.java.net/browse/JDK-8163076 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8163076/webrev.00/ Chris

Review Request: 8154895 Revisit javapackager module path related options

Hi Kevin, This change aligns the CLI of the Java Packager with the rest of the Java toolchain (-modulepath, -addmods, -limitmods and -m). Developers can continue to use the old style -srcfiles, -appClass and -BmainJar= CLI arguments to bundle non-modular applications. JIRA:

Re: javapackager

t;> > >> yum install libX11 > > > > What is the Linux system you are running? > > It is a version of CentOS. (Created within my company with minor tweaks > for branding purposes.) > > > >> > >> It seems to be that javapackager has made a mistake and is cla

Re: javapackager

urposes.) When submitting a bug, make sure the test case works on Oracle Linux or Ubuntu since those are the only “supported” version of Linux. > > >>> >>> It seems to be that javapackager has made a mistake and is claiming to >>> depend on the 32-bit packages even thoug

Re: javapackager

pal...@gmail.com>> wrote: > >> > >> Note that this is a RPM-based system, apt-get is not available, yum is. > >> > >> yum install libX11 > > > > What is the Linux system you are running? > > It is a version of CentOS. (Created within my c

Re: javapackager

tall libX11 > > What is the Linux system you are running? It is a version of CentOS. (Created within my company with minor tweaks for branding purposes.) >> >> It seems to be that javapackager has made a mistake and is claiming to >> depend on the 32-bit packages even tho

Re: javapackager

g to > do as something else is very likely to go wrong (often causing > much more problems). > > Protected multilib versions: alsa-lib-1.0.28-2.el7.i686 != > alsa-lib-1.0.27.2-3.el7.x86_64 > > > It seems to be that javapackager has made a mistake and is claiming

javapackager

What's the best place to go to get help with using the javapackager ? I've read the docs, but things aren't working smoothly and it would be helpful if there were some known working examples to base things on. I'm not finding any examples that use the -daemon or -BserviceHint=true options

Re: javapackager

This list or the Deployment blog (https://blogs.oracle.com/talkingjavadeployment/) are the best places to get help with the javapackager. Is your app built with the 64-bit or 32-bit packager? I noticed “x86_64” appended to the name. If it’s 32-bit you could try running: sudo apt-get install

Re: javapackager

The “-1.x86-64” is something that javapackager automatically appends. I just confirmed that $JAVA_HOME/bin/java -version indicates the 64-bit VM. I’m invoking javapackager via an Exec task in my Gradle build script. (I’m not using the JavaFX plugin because it has even less documentation

Re: javapackager

ost never the correct thing to do as something else is very likely to go wrong (often causing much more problems). Protected multilib versions: alsa-lib-1.0.28-2.el7.i686 != alsa-lib-1.0.27.2-3.el7.x86_64 It seems to be that javapackager has made a mistake and is claiming

  1   2   >