Re: Filling the Packager gap - again

[Kustaa Nyholm]

Thanks!

Yes, I've since downloaded the jdk-13 version and moved to experimenting 
directly with jpackage 
without the ant component to reduce the number of variables.

Now the .app seems to be produced without errors (does not yet run though, need 
to get my ducks in a row first).

But the custom icons and other resources are not picked up.

I posted a question on the core-libs-dev list as this is what the 
https://jdk.java.net/jpackage/ page specified.

wbr Kusti



> On 14 Jan 2019, at 12.27, Rachel Greenham  wrote:
> 
> There have been updates since then. In particular, you can now find it hosted 
> here: https://jdk.java.net/jpackage/
> 
> What you download is an EA build of jdk-13 which includes jpackage. You just 
> use the jpackage that's in that. (You don't have to use that JDK for anything 
> else, just literally set a path to that jpackage binary and run it.) Up to 
> date options in the JEP: https://bugs.openjdk.java.net/browse/JDK-8200758
> 
> No idea if the latest fixes your issues. I'm currently only using it on 
> Windows where (with a bit of fighting) it's working "good enough for now", 
> although updates don't remove the previously installed version of your app 
> from the registry like they should yet.
> 
> -- 
> Rachel
> 
> On 13/01/2019 12:44, Kustaa Nyholm wrote:
>> Hi,
>> 
>> I've been struggling with packaging my app on MacOs High Sierra (10.13.6) 
>> with OpenJDK 11.0.1
>> 
>> 
>> Literally I've put days into this.
>> 
>> Won't bore you will all the details (unless you want) but my latest attempt 
>> is based on this
>> and hence I'm addressing this list:
>> 
>> https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html
>> 
>> Specifically I downloaded
>> 
>> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
>> 
>> and copied:
>> 
>> jpackager -> 
>> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin
>> jdk.packager.jar -> 
>> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin
>> 
>> 
>> I also have (copied from jdk1.8.0_102):
>> 
>> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/ant-javafx.jar
>> 
>> The build works in that it produces a working .dmg and .app with correct 
>> icons and all '
>> (in 
>> /private/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler7020007958604602553/images/EazyCNC-tmp.dmg
>>  etc)
>> but the build ends with an unspecified failure (unless it is related to the 
>> 'already an item with that name.'):
>> 
>> Building DMG package for EazyCNC
>>   Using custom package resource [Bundle config file]  (loaded from 
>> package/macosx/Info.plist)
>>   Using custom package resource [icon]  (loaded from 
>> package/macosx/EazyCNC.icns)
>> Did not find a key matching 'Developer ID Application: '
>>   Config files are saved to 
>> /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx.
>>  Use them to customize package.
>>   Using custom package resource [dmg background]  (loaded from 
>> package/macosx/EazyCNC-background.png)
>>   Using custom package resource [volume icon]  (loaded from 
>> package/macosx/EazyCNC-volume.icns)
>> Using default package resource [script to run after application image is 
>> populated]  (add package/macosx/EazyCNC-post-image.sh to the class path to 
>> customize)
>>   Using custom package resource [DMG setup script]  (loaded from 
>> package/macosx/EazyCNC-dmg-setup.scpt)
>> /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx/EazyCNC-dmg-setup.scpt:631:738:
>>  execution error: Finder got an error: The operation can’t be completed 
>> because there is already an item with that name. (-48)
>>   Config files are saved to 
>> /var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx.
>>  Use them to customize package.
>> 
>> BUILD FAILED
>> /Users/nyholku/EazyCNC-Project/build.xml:305: Error: Bundler "DMG Installer" 
>> (dmg) failed to produce a bundle.
>> 
>> Total time: 6 seconds
>> 
>> Any suggestions to how to dig this further or anything would be highly 
>> appreciated.
>> 
>> I'm pretty sure I've tried all the workarounds and suggestions that google 
>> can find.
>> 
>> 
>> wbr Kusti
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

Re: Filling the Packager gap - again

[Rachel Greenham]

There have been updates since then. In particular, you can now find it 
hosted here: https://jdk.java.net/jpackage/


What you download is an EA build of jdk-13 which includes jpackage. You 
just use the jpackage that's in that. (You don't have to use that JDK 
for anything else, just literally set a path to that jpackage binary and 
run it.) Up to date options in the JEP: 
https://bugs.openjdk.java.net/browse/JDK-8200758


No idea if the latest fixes your issues. I'm currently only using it on 
Windows where (with a bit of fighting) it's working "good enough for 
now", although updates don't remove the previously installed version of 
your app from the registry like they should yet.


--
Rachel

On 13/01/2019 12:44, Kustaa Nyholm wrote:

Hi,

I've been struggling with packaging my app on MacOs High Sierra (10.13.6) with 
OpenJDK 11.0.1


Literally I've put days into this.

Won't bore you will all the details (unless you want) but my latest attempt is 
based on this
and hence I'm addressing this list:

https://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html

Specifically I downloaded

http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip

and copied:

jpackager -> /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin
jdk.packager.jar -> 
/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/bin


I also have (copied from jdk1.8.0_102):

/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/ant-javafx.jar

The build works in that it produces a working .dmg and .app with correct icons 
and all '
(in 
/private/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler7020007958604602553/images/EazyCNC-tmp.dmg
 etc)
but the build ends with an unspecified failure (unless it is related to the 
'already an item with that name.'):

Building DMG package for EazyCNC
   Using custom package resource [Bundle config file]  (loaded from 
package/macosx/Info.plist)
   Using custom package resource [icon]  (loaded from 
package/macosx/EazyCNC.icns)
Did not find a key matching 'Developer ID Application: '
   Config files are saved to 
/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx.
 Use them to customize package.
   Using custom package resource [dmg background]  (loaded from 
package/macosx/EazyCNC-background.png)
   Using custom package resource [volume icon]  (loaded from 
package/macosx/EazyCNC-volume.icns)
Using default package resource [script to run after application image is 
populated]  (add package/macosx/EazyCNC-post-image.sh to the class path to 
customize)
   Using custom package resource [DMG setup script]  (loaded from 
package/macosx/EazyCNC-dmg-setup.scpt)
/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx/EazyCNC-dmg-setup.scpt:631:738:
 execution error: Finder got an error: The operation can’t be completed because 
there is already an item with that name. (-48)
   Config files are saved to 
/var/folders/p_/pl6_ggsn1l91rhjklbxk__rcs_tcs9/T/fxbundler18114117913034428425/macosx.
 Use them to customize package.

BUILD FAILED
/Users/nyholku/EazyCNC-Project/build.xml:305: Error: Bundler "DMG Installer" 
(dmg) failed to produce a bundle.

Total time: 6 seconds

Any suggestions to how to dig this further or anything would be highly 
appreciated.

I'm pretty sure I've tried all the workarounds and suggestions that google can 
find.


wbr Kusti

Re: Filling the Packager gap

[Sverre Moe]

Den fre. 14. des. 2018 kl. 13:47 skrev Johan Vos :

> Hi Sverre,
>
> Scene Builder 11 is built using that backported packager, but not
> everything was working yet.
> It is not the intention to make a real product based on this backported
> code -- we just did it to fill the gap until the jpackage tool is available.
>
> My understanding is that once the jpackage tool is released, you should be
> able to use it to bundle Java(FX) 11 based apps.
>
> The first EA version of the jpackage tool is available now, so I think
> this is now the way forward: http://jdk.java.net/jpackage/
>
> - Johan
>

Thanks for the clarification. I have been looking through the source code
of your backported jpackager to gain some insight, and I should perhaps
instead be looking at the main source code for the jpackage.

I will start using this JDK12 build of jpackager and see if it has the same
issues regarding the bundle resources.
Perhaps also the core-libs-...@openjdk.java.net is the better place to
discuss jpackage on forward. I reported some issues with jpackage some time
ago that has been added to its JDK bugs list.

/Sverre

Re: Filling the Packager gap

[Kevin Rushforth]

[including Andy]

On 12/13/2018 10:25 AM, Sverre Moe wrote:

Has anyone been able to use jpackager with bundle resources?
The jpackager says to put these on the class path
Using default package resource [menu icon]  (add package/linux/app.png to
the class path to customize)
Using default package resource [Menu shortcut descriptor]  (add
package/linux/app.desktop to the class path to customize)
Using default package resource [RPM spec file]  (add package/linux/app.spec
to the class path to customize)
I have mentioned on corejdk mailinglist that the help output should mention
how to do this.
The jpackager does not support any classpath argument. The old javapackager
did have an argument for setting classpath.
Editing the jpackager bash script to include "-cp
/path/to/project/build/deploy/" does not work.
Considering that jdk.packager is a java module, I even tried to add the
directory where package/linux is to the module-path.
--module-path "/path/to/project/build/deploy":${JAVA_PACKAGER_PATH}


Andy can probably comment on this.


It seems jpackager has been re-targeted for Java 13. I just hope it will
continue to be usable for package Java 11 applications. The backported
jpackager is working fine except for this resource problem.


Yes, the jpackage tool (recently renamed to drop the 'r') will have the 
ability to package JDK 11 applications.


-- Kevin

Re: Filling the Packager gap

[Sverre Moe]

Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos :

> Hi,
>
> As promised, we looked into an interim solution for the packager-gap. Work
> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
> We backported the required changes to an OpenJDK 11 mirror:
> https://github.com/johanvos/openjdk-mobile11/tree/packager
>
> With this, we created modified OpenJDK 11 builds that contain the packager
> (wrapper/exe + module including native library). They can be downloaded and
> tested/used at
>
> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>
> For Windows, you have to unzip the bundle in the same directory as the JDK,
> as the packager wrapper expect to find the java binary at the same level.
>
> Note that these are not products. We use them internally to create
> installers (e.g. we're using them for Scene Builder 11 and that works
> fine), and they do what we expect them to do, but there are no guarantees
> of course so at least for now I recommend using them in development only
> (or even better, look at the changes and contribute to
> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
>
> - Johan
>


Has anyone been able to use jpackager with bundle resources?
The jpackager says to put these on the class path
Using default package resource [menu icon]  (add package/linux/app.png to
the class path to customize)
Using default package resource [Menu shortcut descriptor]  (add
package/linux/app.desktop to the class path to customize)
Using default package resource [RPM spec file]  (add package/linux/app.spec
to the class path to customize)

I have mentioned on corejdk mailinglist that the help output should mention
how to do this.
The jpackager does not support any classpath argument. The old javapackager
did have an argument for setting classpath.
Editing the jpackager bash script to include "-cp
/path/to/project/build/deploy/" does not work.
Considering that jdk.packager is a java module, I even tried to add the
directory where package/linux is to the module-path.
--module-path "/path/to/project/build/deploy":${JAVA_PACKAGER_PATH}

It seems jpackager has been re-targeted for Java 13. I just hope it will
continue to be usable for package Java 11 applications. The backported
jpackager is working fine except for this resource problem.

/Sverre

Re: Filling the Packager gap

[Sverre Moe]

Johan,
has there been any new updates to jpackager in JDK12 since you backported
it?

I have found some problems with jpackager. Perhaps they might have been
fixed later.
I mentioned this to core-list-dev mailinglist on jpackager thread.

1)
The control file for debian package does not set correct description

--name test
--description This is a Test Application

/tmp/jdk.packager607148779833718376/linux/control
Package: test
Description: test

The RPM gets it correctly
Summary : test
Description :
This is a Test Application

2)
Category is not set on either DEB or RPM
  --category
  Category or group of the application.
--category "Some/Category/Application"
Group: Unspecified
Section: unknown

Perhaps I have misunderstood what this category is for, because I see this
it is set in the generated application.desktop, but It should definitely
also be set in the RPM and DEB.

/Sverre

Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos :

> Hi,
>
> As promised, we looked into an interim solution for the packager-gap. Work
> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
> We backported the required changes to an OpenJDK 11 mirror:
> https://github.com/johanvos/openjdk-mobile11/tree/packager
>
> With this, we created modified OpenJDK 11 builds that contain the packager
> (wrapper/exe + module including native library). They can be downloaded and
> tested/used at
>
> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>
> For Windows, you have to unzip the bundle in the same directory as the JDK,
> as the packager wrapper expect to find the java binary at the same level.
>
> Note that these are not products. We use them internally to create
> installers (e.g. we're using them for Scene Builder 11 and that works
> fine), and they do what we expect them to do, but there are no guarantees
> of course so at least for now I recommend using them in development only
> (or even better, look at the changes and contribute to
> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
>
> - Johan
>

Re: Filling the Packager gap

[Dean Wookey]

Hi,

I got jpackager working with OpenJDK11.0.1 after a bit of trial and error.
I'm now able to create a windows image like I had before with javapackager.
I thought I'd share some of the issues I've had in case it helps anyone out.

The first one was that you need to copy jdk.packager.jar not only into the
bin directory, but also into the jmods directory. If you don't, you get a
cryptic nullpointer exception from the jpackager in verbose mode. I'm sure
it's expecting a jdk.packager.jmod there that contains the list of files
it's looking for.

The second is that --jvm-args only seems to respect the first instance of
an argument. For example, you can have multiple--add-exports arguments. All
of them will get stored in the cfg file in the image's app directory, but
only the first instance will get passed to the jvm by the native executable.

Otherwise, works well, at least for our needs. Thank you.

Dean

On Wed, Sep 19, 2018 at 10:56 AM Johan Vos  wrote:

> Hi,
>
> As promised, we looked into an interim solution for the packager-gap. Work
> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
> We backported the required changes to an OpenJDK 11 mirror:
> https://github.com/johanvos/openjdk-mobile11/tree/packager
>
> With this, we created modified OpenJDK 11 builds that contain the packager
> (wrapper/exe + module including native library). They can be downloaded and
> tested/used at
>
> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>
> For Windows, you have to unzip the bundle in the same directory as the JDK,
> as the packager wrapper expect to find the java binary at the same level.
>
> Note that these are not products. We use them internally to create
> installers (e.g. we're using them for Scene Builder 11 and that works
> fine), and they do what we expect them to do, but there are no guarantees
> of course so at least for now I recommend using them in development only
> (or even better, look at the changes and contribute to
> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
>
> - Johan
>

Re: Filling the Packager gap

[Sverre Moe]

I am having some problems accessing the jpackager from symlinks, seems it
cannot find the jdk.packager.jar

/usr/bin/jpackager -> /etc/alternatives/jpackager
/etc/alternatives/jpackager -> /usr/java/jpackager/jpackager

:/ # jpackager --help
Error occurred during initialization of boot layer
java.lang.module.FindException: Module jdk.packager not found

Though accessing the jpackager directly works fine:
/usr/java/jpackager/jpackager

Any suggestion what the problem might be and how to remedy this?

/Sverre

Re: Filling the Packager gap

[Ty Young]

On 9/27/18 1:44 AM, Johan Vos wrote:

Hi Ty,

Apart om jdk.jlink, who else is 
exporting jdk.tools.jlink.internal.packager ?

If that is the case, there must be something wrong.
The 12-sandbox version also exports that package: 
http://hg.openjdk.java.net/jdk/sandbox/file/6972c0e75e23/src/jdk.jlink/share/classes/module-info.java


- Johan



JavaFX itself is:


rt/apps/performance/JavaFX/src/jdk.jlink/classes(It's just an app)

module-info.java.extra from /rt/dependencies/jdk.jlink

module-info.java.extra from /rt/build/modular-sdk/modules_src/jdk.jlink


I don't know what the .extra is all about. I found those by searching 
for all the module-info files from in JavaFX and seeing if there was any 
matches to jdk.tools.jlink.internal.packager.




On Thu, Sep 27, 2018 at 4:14 AM Ty Young > wrote:



On 9/19/18 3:55 AM, Johan Vos wrote:
> Hi,
>
> As promised, we looked into an interim solution for the
packager-gap. Work
> for the new Java Packager (12?) is being done in the OpenJDK
sandbox repo.
> We backported the required changes to an OpenJDK 11 mirror:
> https://github.com/johanvos/openjdk-mobile11/tree/packager
>
> With this, we created modified OpenJDK 11 builds that contain
the packager
> (wrapper/exe + module including native library). They can be
downloaded and
> tested/used at
>
> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>
> For Windows, you have to unzip the bundle in the same directory
as the JDK,
> as the packager wrapper expect to find the java binary at the
same level.
>
> Note that these are not products. We use them internally to create
> installers (e.g. we're using them for Scene Builder 11 and that
works
> fine), and they do what we expect them to do, but there are no
guarantees
> of course so at least for now I recommend using them in
development only
> (or even better, look at the changes and contribute to
> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this
backport)
>
> - Johan


The JDK source fails to compile due to a duplicate qualified export.
Removing the export from
openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java

fixes it.


By the way, how does one use this with jLink generated by Netbeans? I
used the jLink build as the input and it just dumped it into the
"app"
folder when making the image which doesn't work.

Re: Filling the Packager gap

[Sverre Moe]

Den tor. 27. sep. 2018 kl. 18:50 skrev Kevin Rushforth <
kevin.rushfo...@oracle.com>:

> You mean openjfx11, not JDK 11, right? Backporting this fix would mean an
> openjfx 11.x update release would stop building or running with JDK 10. Not
> something that would be done lightly, since it would break the "FX N runs
> with JDK N-1" policy we have been discussing lately. There is an easy
> workaround for that bug that needs to be done when running "jlink" to
> create your image. It's documented in the release notes.
>
> -- Kevin
>

Yes, I meant OpenJFX 11. I will take a look at the release notes to find
the workaround.

/Sverre

Re: Filling the Packager gap

[Kevin Rushforth]

You mean openjfx11, not JDK 11, right? Backporting this fix would mean 
an openjfx 11.x update release would stop building or running with JDK 
10. Not something that would be done lightly, since it would break the 
"FX N runs with JDK N-1" policy we have been discussing lately. There is 
an easy workaround for that bug that needs to be done when running 
"jlink" to create your image. It's documented in the release notes.


-- Kevin



On 9/27/2018 9:27 AM, Sverre Moe wrote:
Any chance of getting the fix for JDK-8210759 backported to JDK 11? I 
remember reading the OpenJDK will be patched up to 2023 (while Oracle 
JDK will be patched up to 2026).
We deliver software that our customers could be running for a decade 
or more. The LTS is the version we will then target when we move away 
from Java 8.


/Sverre

Den tor. 27. sep. 2018 kl. 18:18 skrev Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>>:


I missed seeing the swing exception in your earlier message. Yes,
the Swing issue is a known problem in openjfx11, JDK-8210759 [1],
and is documented in the release notes [2].

It will be fixed in openjfx12 just as soon as I push the fix for
JDK-8210092 [3] later today (the review was just finished earlier
this morning). This was one of the bugs waiting until the fix
requiring JDK 11 for openjfx 12 was pushed.

As for your other question, yes, if you add the javafx.* modules
to your Java runtime image, then that runtime image contains the
javafx.* modules. If your application were modularized, then the
Java runtime image would contain your application, too.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8210759
[2]

https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues
[3] https://bugs.openjdk.java.net/browse/JDK-8210092


On 9/27/2018 9:03 AM, Sverre Moe wrote:

Without the reliance on javafx-swing I was able to create an
image, package and execute my test application.
Is the Swing problem a known bug in JavaFX 11?

The jlink runtime image I reckon now also contains the JavaFX
modules? Seems unnecessary when they already are dependencies.

/Sverre

Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe
mailto:sverre@gmail.com>>:

Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>:

No, jlink won't link in a non-modular application. So the
steps are:

1) Run jlink to create a Java runtime image, possibly
stripped down, and
include the javafx.* modules you need
2) Run jpackager to package your non-modular application
with the above
Java runtime image.

-- Kevin


So we have to create the image with the jlink first before we
use jpackager, and we have to link in with the javafx
modules. We cannot use the javafx dependencies in the project?

jlink --add-modules=ALL-SYSTEM --output image
Error: Module ALL-SYSTEM not found

The just to make sure we have everything we need I add the
actual modules
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --output
image

Linking in with the JavaFX jmods from Gluon:
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging
--module-path /usr/java/javafx-jmods-11/
--add-modules=javafx.base --add-modules=javafx.controls
--add-modules=javafx.fxml --add-modules=javafx.graphics
--add-modules=javafx.web --add-modules=javafx.media
--add-modules=javafx.swing --output image

I managed to build our Java 8 project with Java 11, using the
JavaFX dependencies.
Then using jpackager with the runtime image from jlink
/usr/java/jpackager/jpackager create-installer --input
build/distributions/application-1.0.0-SNAPSHOT/lib/ --output
outputDir --runtime-image image/ --verbose --echo-mode
--main-jar application-1.0.0-SNAPSHOT.jar

Running the application image from jpackager
First try:
I thought I had added all necessary modules to the runtime
image, but I needed one more, java.management.

Second try:
InteropFactory: cannot load
com.sun.javafx.embed.swing.newimpl.InteropFactoryN
Exception in thread "GUIBuilderWorker"
java.lang.IllegalAccessError: class
com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in
module javafx.swing) cannot access class
sun.swing.JLightweightFrame (in module java.desktop) because
module java.desktop does not export sun.swing to 

Re: Filling the Packager gap

[Sverre Moe]

Any chance of getting the fix for JDK-8210759 backported to JDK 11? I
remember reading the OpenJDK will be patched up to 2023 (while Oracle JDK
will be patched up to 2026).
We deliver software that our customers could be running for a decade or
more. The LTS is the version we will then target when we move away from
Java 8.

/Sverre

Den tor. 27. sep. 2018 kl. 18:18 skrev Kevin Rushforth <
kevin.rushfo...@oracle.com>:

> I missed seeing the swing exception in your earlier message. Yes, the
> Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is
> documented in the release notes [2].
>
> It will be fixed in openjfx12 just as soon as I push the fix for
> JDK-8210092 [3] later today (the review was just finished earlier this
> morning). This was one of the bugs waiting until the fix requiring JDK 11
> for openjfx 12 was pushed.
>
> As for your other question, yes, if you add the javafx.* modules to your
> Java runtime image, then that runtime image contains the javafx.* modules.
> If your application were modularized, then the Java runtime image would
> contain your application, too.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8210759
> [2]
> https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues
> [3] https://bugs.openjdk.java.net/browse/JDK-8210092
>
>
> On 9/27/2018 9:03 AM, Sverre Moe wrote:
>
> Without the reliance on javafx-swing I was able to create an image,
> package and execute my test application.
> Is the Swing problem a known bug in JavaFX 11?
>
> The jlink runtime image I reckon now also contains the JavaFX modules?
> Seems unnecessary when they already are dependencies.
>
> /Sverre
>
> Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe :
>
>> Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth <
>> kevin.rushfo...@oracle.com>:
>>
>>> No, jlink won't link in a non-modular application. So the steps are:
>>>
>>> 1) Run jlink to create a Java runtime image, possibly stripped down, and
>>> include the javafx.* modules you need
>>> 2) Run jpackager to package your non-modular application with the above
>>> Java runtime image.
>>>
>>> -- Kevin
>>>
>>
>> So we have to create the image with the jlink first before we use
>> jpackager, and we have to link in with the javafx modules. We cannot use
>> the javafx dependencies in the project?
>>
>> jlink --add-modules=ALL-SYSTEM --output image
>> Error: Module ALL-SYSTEM not found
>>
>> The just to make sure we have everything we need I add the actual modules
>> jlink --add-modules=java.base --add-modules=java.desktop
>> --add-modules=java.net.http --add-modules=java.xml
>> --add-modules=java.prefs --add-modules=java.logging --output image
>>
>> Linking in with the JavaFX jmods from Gluon:
>> jlink --add-modules=java.base --add-modules=java.desktop
>> --add-modules=java.net.http --add-modules=java.xml
>> --add-modules=java.prefs --add-modules=java.logging --module-path
>> /usr/java/javafx-jmods-11/ --add-modules=javafx.base
>> --add-modules=javafx.controls --add-modules=javafx.fxml
>> --add-modules=javafx.graphics --add-modules=javafx.web
>> --add-modules=javafx.media --add-modules=javafx.swing --output image
>>
>> I managed to build our Java 8 project with Java 11, using the JavaFX
>> dependencies.
>> Then using jpackager with the runtime image from jlink
>> /usr/java/jpackager/jpackager create-installer --input
>> build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir
>> --runtime-image image/ --verbose --echo-mode --main-jar
>> application-1.0.0-SNAPSHOT.jar
>>
>> Running the application image from jpackager
>> First try:
>> I thought I had added all necessary modules to the runtime image, but I
>> needed one more, java.management.
>>
>> Second try:
>> InteropFactory: cannot load
>> com.sun.javafx.embed.swing.newimpl.InteropFactoryN
>> Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError:
>> class com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module
>> javafx.swing) cannot access class sun.swing.JLightweightFrame (in module
>> java.desktop) because module java.desktop does not export sun.swing to
>> module javafx.swing
>>at
>> javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71)
>>at
>> javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)
>>at
>> javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271)
>>at no.company.application.fx.MySwingComponent.initNode(
>> MySwingComponent.java:155)
>>
>> The module java.desktop should include the AWT/Swing.
>>
>> At least I now have been able to create an native application using both
>> jlink and the new jpackager.
>>
>> /Sverre
>>
>
>

Re: Filling the Packager gap

[Kevin Rushforth]

I missed seeing the swing exception in your earlier message. Yes, the 
Swing issue is a known problem in openjfx11, JDK-8210759 [1], and is 
documented in the release notes [2].


It will be fixed in openjfx12 just as soon as I push the fix for 
JDK-8210092 [3] later today (the review was just finished earlier this 
morning). This was one of the bugs waiting until the fix requiring JDK 
11 for openjfx 12 was pushed.


As for your other question, yes, if you add the javafx.* modules to your 
Java runtime image, then that runtime image contains the javafx.* 
modules. If your application were modularized, then the Java runtime 
image would contain your application, too.


-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8210759
[2] 
https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md#known-issues

[3] https://bugs.openjdk.java.net/browse/JDK-8210092


On 9/27/2018 9:03 AM, Sverre Moe wrote:
Without the reliance on javafx-swing I was able to create an image, 
package and execute my test application.

Is the Swing problem a known bug in JavaFX 11?

The jlink runtime image I reckon now also contains the JavaFX modules? 
Seems unnecessary when they already are dependencies.


/Sverre

Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe 
mailto:sverre@gmail.com>>:


Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>:

No, jlink won't link in a non-modular application. So the
steps are:

1) Run jlink to create a Java runtime image, possibly stripped
down, and
include the javafx.* modules you need
2) Run jpackager to package your non-modular application with
the above
Java runtime image.

-- Kevin


So we have to create the image with the jlink first before we use
jpackager, and we have to link in with the javafx modules. We
cannot use the javafx dependencies in the project?

jlink --add-modules=ALL-SYSTEM --output image
Error: Module ALL-SYSTEM not found

The just to make sure we have everything we need I add the actual
modules
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --output image

Linking in with the JavaFX jmods from Gluon:
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml
--add-modules=java.prefs --add-modules=java.logging --module-path
/usr/java/javafx-jmods-11/ --add-modules=javafx.base
--add-modules=javafx.controls --add-modules=javafx.fxml
--add-modules=javafx.graphics --add-modules=javafx.web
--add-modules=javafx.media --add-modules=javafx.swing --output image

I managed to build our Java 8 project with Java 11, using the
JavaFX dependencies.
Then using jpackager with the runtime image from jlink
/usr/java/jpackager/jpackager create-installer --input
build/distributions/application-1.0.0-SNAPSHOT/lib/ --output
outputDir --runtime-image image/ --verbose --echo-mode --main-jar
application-1.0.0-SNAPSHOT.jar

Running the application image from jpackager
First try:
I thought I had added all necessary modules to the runtime image,
but I needed one more, java.management.

Second try:
InteropFactory: cannot load
com.sun.javafx.embed.swing.newimpl.InteropFactoryN
Exception in thread "GUIBuilderWorker"
java.lang.IllegalAccessError: class
com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module
javafx.swing) cannot access class sun.swing.JLightweightFrame (in
module java.desktop) because module java.desktop does not export
sun.swing to module javafx.swing
   at

javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71)
   at

javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)
   at
javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271)
   at

no.company.application.fx.MySwingComponent.initNode(MySwingComponent.java:155)

The module java.desktop should include the AWT/Swing.

At least I now have been able to create an native application
using both jlink and the new jpackager.

/Sverre

Re: Filling the Packager gap

[Sverre Moe]

Without the reliance on javafx-swing I was able to create an image, package
and execute my test application.
Is the Swing problem a known bug in JavaFX 11?

The jlink runtime image I reckon now also contains the JavaFX modules?
Seems unnecessary when they already are dependencies.

/Sverre

Den tor. 27. sep. 2018 kl. 10:42 skrev Sverre Moe :

> Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth <
> kevin.rushfo...@oracle.com>:
>
>> No, jlink won't link in a non-modular application. So the steps are:
>>
>> 1) Run jlink to create a Java runtime image, possibly stripped down, and
>> include the javafx.* modules you need
>> 2) Run jpackager to package your non-modular application with the above
>> Java runtime image.
>>
>> -- Kevin
>>
>
> So we have to create the image with the jlink first before we use
> jpackager, and we have to link in with the javafx modules. We cannot use
> the javafx dependencies in the project?
>
> jlink --add-modules=ALL-SYSTEM --output image
> Error: Module ALL-SYSTEM not found
>
> The just to make sure we have everything we need I add the actual modules
> jlink --add-modules=java.base --add-modules=java.desktop
> --add-modules=java.net.http --add-modules=java.xml
> --add-modules=java.prefs --add-modules=java.logging --output image
>
> Linking in with the JavaFX jmods from Gluon:
> jlink --add-modules=java.base --add-modules=java.desktop
> --add-modules=java.net.http --add-modules=java.xml
> --add-modules=java.prefs --add-modules=java.logging --module-path
> /usr/java/javafx-jmods-11/ --add-modules=javafx.base
> --add-modules=javafx.controls --add-modules=javafx.fxml
> --add-modules=javafx.graphics --add-modules=javafx.web
> --add-modules=javafx.media --add-modules=javafx.swing --output image
>
> I managed to build our Java 8 project with Java 11, using the JavaFX
> dependencies.
> Then using jpackager with the runtime image from jlink
> /usr/java/jpackager/jpackager create-installer --input
> build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir
> --runtime-image image/ --verbose --echo-mode --main-jar
> application-1.0.0-SNAPSHOT.jar
>
> Running the application image from jpackager
> First try:
> I thought I had added all necessary modules to the runtime image, but I
> needed one more, java.management.
>
> Second try:
> InteropFactory: cannot load
> com.sun.javafx.embed.swing.newimpl.InteropFactoryN
> Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: class
> com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module
> javafx.swing) cannot access class sun.swing.JLightweightFrame (in module
> java.desktop) because module java.desktop does not export sun.swing to
> module javafx.swing
>at
> javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71)
>
>at
> javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)
>
>at
> javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271)
>at no.company.application.fx.MySwingComponent.initNode(
> MySwingComponent.java:155)
>
> The module java.desktop should include the AWT/Swing.
>
> At least I now have been able to create an native application using both
> jlink and the new jpackager.
>
> /Sverre
>

Re: Filling the Packager gap

[Sverre Moe]

Den tor. 27. sep. 2018 kl. 00:49 skrev Kevin Rushforth <
kevin.rushfo...@oracle.com>:

> No, jlink won't link in a non-modular application. So the steps are:
>
> 1) Run jlink to create a Java runtime image, possibly stripped down, and
> include the javafx.* modules you need
> 2) Run jpackager to package your non-modular application with the above
> Java runtime image.
>
> -- Kevin
>

So we have to create the image with the jlink first before we use
jpackager, and we have to link in with the javafx modules. We cannot use
the javafx dependencies in the project?

jlink --add-modules=ALL-SYSTEM --output image
Error: Module ALL-SYSTEM not found

The just to make sure we have everything we need I add the actual modules
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml --add-modules=java.prefs
--add-modules=java.logging --output image

Linking in with the JavaFX jmods from Gluon:
jlink --add-modules=java.base --add-modules=java.desktop
--add-modules=java.net.http --add-modules=java.xml --add-modules=java.prefs
--add-modules=java.logging --module-path /usr/java/javafx-jmods-11/
--add-modules=javafx.base --add-modules=javafx.controls
--add-modules=javafx.fxml --add-modules=javafx.graphics
--add-modules=javafx.web --add-modules=javafx.media
--add-modules=javafx.swing --output image

I managed to build our Java 8 project with Java 11, using the JavaFX
dependencies.
Then using jpackager with the runtime image from jlink
/usr/java/jpackager/jpackager create-installer --input
build/distributions/application-1.0.0-SNAPSHOT/lib/ --output outputDir
--runtime-image image/ --verbose --echo-mode --main-jar
application-1.0.0-SNAPSHOT.jar

Running the application image from jpackager
First try:
I thought I had added all necessary modules to the runtime image, but I
needed one more, java.management.

Second try:
InteropFactory: cannot load
com.sun.javafx.embed.swing.newimpl.InteropFactoryN
Exception in thread "GUIBuilderWorker" java.lang.IllegalAccessError: class
com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO (in module
javafx.swing) cannot access class sun.swing.JLightweightFrame (in module
java.desktop) because module java.desktop does not export sun.swing to
module javafx.swing
   at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.SwingNodeInteropO.(SwingNodeInteropO.java:71)

   at
javafx.swing/com.sun.javafx.embed.swing.oldimpl.InteropFactoryO.createSwingNodeImpl(InteropFactoryO.java:42)

   at
javafx.swing/javafx.embed.swing.SwingNode.(SwingNode.java:271)
   at no.company.application.fx.MySwingComponent.initNode(
MySwingComponent.java:155)

The module java.desktop should include the AWT/Swing.

At least I now have been able to create an native application using both
jlink and the new jpackager.

/Sverre

Re: Filling the Packager gap

[Johan Vos]

Hi Ty,

Apart om jdk.jlink, who else is exporting jdk.tools.jlink.internal.packager
?
If that is the case, there must be something wrong.
The 12-sandbox version also exports that package:
http://hg.openjdk.java.net/jdk/sandbox/file/6972c0e75e23/src/jdk.jlink/share/classes/module-info.java

- Johan

On Thu, Sep 27, 2018 at 4:14 AM Ty Young  wrote:

>
> On 9/19/18 3:55 AM, Johan Vos wrote:
> > Hi,
> >
> > As promised, we looked into an interim solution for the packager-gap.
> Work
> > for the new Java Packager (12?) is being done in the OpenJDK sandbox
> repo.
> > We backported the required changes to an OpenJDK 11 mirror:
> > https://github.com/johanvos/openjdk-mobile11/tree/packager
> >
> > With this, we created modified OpenJDK 11 builds that contain the
> packager
> > (wrapper/exe + module including native library). They can be downloaded
> and
> > tested/used at
> >
> > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
> > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
> > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
> >
> > For Windows, you have to unzip the bundle in the same directory as the
> JDK,
> > as the packager wrapper expect to find the java binary at the same level.
> >
> > Note that these are not products. We use them internally to create
> > installers (e.g. we're using them for Scene Builder 11 and that works
> > fine), and they do what we expect them to do, but there are no guarantees
> > of course so at least for now I recommend using them in development only
> > (or even better, look at the changes and contribute to
> > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
> >
> > - Johan
>
>
> The JDK source fails to compile due to a duplicate qualified export.
> Removing the export from
> openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java
> fixes it.
>
>
> By the way, how does one use this with jLink generated by Netbeans? I
> used the jLink build as the input and it just dumped it into the "app"
> folder when making the image which doesn't work.
>
>
>
>

Re: Filling the Packager gap

[Ty Young]

On 9/19/18 3:55 AM, Johan Vos wrote:

Hi,

As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
We backported the required changes to an OpenJDK 11 mirror:
https://github.com/johanvos/openjdk-mobile11/tree/packager

With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at

http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip

For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.

Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)

- Johan



The JDK source fails to compile due to a duplicate qualified export. 
Removing the export from 
openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java 
fixes it.



By the way, how does one use this with jLink generated by Netbeans? I 
used the jLink build as the input and it just dumped it into the "app" 
folder when making the image which doesn't work.

Re: Filling the Packager gap

[Kevin Rushforth]

No, jlink won't link in a non-modular application. So the steps are:

1) Run jlink to create a Java runtime image, possibly stripped down, and 
include the javafx.* modules you need
2) Run jpackager to package your non-modular application with the above 
Java runtime image.


-- Kevin


On 9/26/2018 3:23 PM, Scott Palmer wrote:

Does jlink work for non-modular stuff?  The last time I tried it complained to 
me too.  I guess it gives up because it can’t automatically figure out module 
dependencies.  The error below shows jlink is what is complaining.

Scott



On Sep 26, 2018, at 3:44 PM, Kevin Rushforth  wrote:

jpackager should work for non-modular applications as well as modular ones. 
We've tested it for simple applications with or without FX. In the latter case, 
the testing I've done has been done by first using jlink to create a Java 
runtime with the needed JDK modules + the openjfx11 modules (using the jomds).

Andy might have additional comments.

-- Kevin


On 9/26/2018 11:50 AM, Sverre Moe wrote:

I have tried this jpackager a bit. It is working fine packaging a Java
modular project.
However it fails to package a none modular project. I modified my project
and removed the modularization and tried again to see if it would work to
package our legacy Java 8 project (though now built with JDK 11 and with
dependencies on openjfx 11).

I was under the impression that the jpackager should also work to package
non-modular projects.

The Gradle distribution task produces an tar archive with all the
dependencies and my own JAR, which I am using as input to the jpackager.

This produces the RPM for the modular project:
sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib>
~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
--verbose --echo-mode --module-path . --module
no.smeaworks.movies/no.smeaworks.movies.MoviesApplication

Using the jpackager to package non modular project:
sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT>
~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output
outputDir --verbose --echo-mode --class
no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar


ECHO-MODE: Running [rpmbuild, --version]

"Adding modules: [] to runtime image."

ECHO-MODE: Running jlink [
--output =
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
--module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
--add-modules = []
--limit-modules = []
--exclude-files = .*\.diz
--strip-native-commands = false
]
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException:
jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
for java.base module
Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
them to customize package.
Exception in thread "main" jdk.packager.internal.PackagerException: Error:
Bundler "RPM Bundle" (rpm) failed to produce a bundle.
at
jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)

at
jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)

at jdk.packager/jdk.packager.Main.run(Main.java:71)
at jdk.packager/jdk.packager.Main.main(Main.java:47)


Is my presumption wrong that it should package also non modular projects,
or am I missing some runtime flags to jpackager?

Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
insight how you use jpackage to build the project? I could not find
anything on it in the Gluon SceneBuilder GitHub repository.

/Sverre

Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos :


Hi,

As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
We backported the required changes to an OpenJDK 11 mirror:
https://github.com/johanvos/openjdk-mobile11/tree/packager

With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at

http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip

For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.

Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to

Re: Filling the Packager gap

[Scott Palmer]

Does jlink work for non-modular stuff?  The last time I tried it complained to 
me too.  I guess it gives up because it can’t automatically figure out module 
dependencies.  The error below shows jlink is what is complaining.

Scott


> On Sep 26, 2018, at 3:44 PM, Kevin Rushforth  
> wrote:
> 
> jpackager should work for non-modular applications as well as modular ones. 
> We've tested it for simple applications with or without FX. In the latter 
> case, the testing I've done has been done by first using jlink to create a 
> Java runtime with the needed JDK modules + the openjfx11 modules (using the 
> jomds).
> 
> Andy might have additional comments.
> 
> -- Kevin
> 
> 
> On 9/26/2018 11:50 AM, Sverre Moe wrote:
>> I have tried this jpackager a bit. It is working fine packaging a Java
>> modular project.
>> However it fails to package a none modular project. I modified my project
>> and removed the modularization and tried again to see if it would work to
>> package our legacy Java 8 project (though now built with JDK 11 and with
>> dependencies on openjfx 11).
>> 
>> I was under the impression that the jpackager should also work to package
>> non-modular projects.
>> 
>> The Gradle distribution task produces an tar archive with all the
>> dependencies and my own JAR, which I am using as input to the jpackager.
>> 
>> This produces the RPM for the modular project:
>> sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib>
>> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
>> --verbose --echo-mode --module-path . --module
>> no.smeaworks.movies/no.smeaworks.movies.MoviesApplication
>> 
>> Using the jpackager to package non modular project:
>> sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT>
>> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib 
>> --output
>> outputDir --verbose --echo-mode --class
>> no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar
>> 
>> 
>> ECHO-MODE: Running [rpmbuild, --version]
>> 
>> "Adding modules: [] to runtime image."
>> 
>> ECHO-MODE: Running jlink [
>> --output =
>> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
>> --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
>> --add-modules = []
>> --limit-modules = []
>> --exclude-files = .*\.diz
>> --strip-native-commands = false
>> ]
>> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
>> Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException:
>> jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
>> for java.base module
>> Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
>> them to customize package.
>> Exception in thread "main" jdk.packager.internal.PackagerException: Error:
>> Bundler "RPM Bundle" (rpm) failed to produce a bundle.
>>at
>> jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)
>> 
>>at
>> jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)
>> 
>>at jdk.packager/jdk.packager.Main.run(Main.java:71)
>>at jdk.packager/jdk.packager.Main.main(Main.java:47)
>> 
>> 
>> Is my presumption wrong that it should package also non modular projects,
>> or am I missing some runtime flags to jpackager?
>> 
>> Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
>> reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
>> insight how you use jpackage to build the project? I could not find
>> anything on it in the Gluon SceneBuilder GitHub repository.
>> 
>> /Sverre
>> 
>> Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos :
>> 
>>> Hi,
>>> 
>>> As promised, we looked into an interim solution for the packager-gap. Work
>>> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
>>> We backported the required changes to an OpenJDK 11 mirror:
>>> https://github.com/johanvos/openjdk-mobile11/tree/packager
>>> 
>>> With this, we created modified OpenJDK 11 builds that contain the packager
>>> (wrapper/exe + module including native library). They can be downloaded and
>>> tested/used at
>>> 
>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>>> 
>>> For Windows, you have to unzip the bundle in the same directory as the JDK,
>>> as the packager wrapper expect to find the java binary at the same level.
>>> 
>>> Note that these are not products. We use them internally to create
>>> installers (e.g. we're using them for Scene Builder 11 and that works
>>> fine), and they do what we expect them to do, but there are no guarantees
>>> of course so at least for now I recommend using them in development only
>>> (or even better, look at the changes and contribute to
>>> 

Re: Filling the Packager gap

[Kevin Rushforth]

jpackager should work for non-modular applications as well as modular 
ones. We've tested it for simple applications with or without FX. In the 
latter case, the testing I've done has been done by first using jlink to 
create a Java runtime with the needed JDK modules + the openjfx11 
modules (using the jomds).


Andy might have additional comments.

-- Kevin


On 9/26/2018 11:50 AM, Sverre Moe wrote:

I have tried this jpackager a bit. It is working fine packaging a Java
modular project.
However it fails to package a none modular project. I modified my project
and removed the modularization and tried again to see if it would work to
package our legacy Java 8 project (though now built with JDK 11 and with
dependencies on openjfx 11).

I was under the impression that the jpackager should also work to package
non-modular projects.

The Gradle distribution task produces an tar archive with all the
dependencies and my own JAR, which I am using as input to the jpackager.

This produces the RPM for the modular project:
sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib>
~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
--verbose --echo-mode --module-path . --module
no.smeaworks.movies/no.smeaworks.movies.MoviesApplication

Using the jpackager to package non modular project:
sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT>
~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output
outputDir --verbose --echo-mode --class
no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar


ECHO-MODE: Running [rpmbuild, --version]

"Adding modules: [] to runtime image."

ECHO-MODE: Running jlink [
--output =
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
--module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
--add-modules = []
--limit-modules = []
--exclude-files = .*\.diz
--strip-native-commands = false
]
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException:
jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
for java.base module
Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
them to customize package.
Exception in thread "main" jdk.packager.internal.PackagerException: Error:
Bundler "RPM Bundle" (rpm) failed to produce a bundle.
at
jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)

at
jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)

at jdk.packager/jdk.packager.Main.run(Main.java:71)
at jdk.packager/jdk.packager.Main.main(Main.java:47)


Is my presumption wrong that it should package also non modular projects,
or am I missing some runtime flags to jpackager?

Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
insight how you use jpackage to build the project? I could not find
anything on it in the Gluon SceneBuilder GitHub repository.

/Sverre

Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos :


Hi,

As promised, we looked into an interim solution for the packager-gap. Work
for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
We backported the required changes to an OpenJDK 11 mirror:
https://github.com/johanvos/openjdk-mobile11/tree/packager

With this, we created modified OpenJDK 11 builds that contain the packager
(wrapper/exe + module including native library). They can be downloaded and
tested/used at

http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip

For Windows, you have to unzip the bundle in the same directory as the JDK,
as the packager wrapper expect to find the java binary at the same level.

Note that these are not products. We use them internally to create
installers (e.g. we're using them for Scene Builder 11 and that works
fine), and they do what we expect them to do, but there are no guarantees
of course so at least for now I recommend using them in development only
(or even better, look at the changes and contribute to
https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)

- Johan

Re: Filling the Packager gap

[Sverre Moe]

I have tried this jpackager a bit. It is working fine packaging a Java
modular project.
However it fails to package a none modular project. I modified my project
and removed the modularization and tried again to see if it would work to
package our legacy Java 8 project (though now built with JDK 11 and with
dependencies on openjfx 11).

I was under the impression that the jpackager should also work to package
non-modular projects.

The Gradle distribution task produces an tar archive with all the
dependencies and my own JAR, which I am using as input to the jpackager.

This produces the RPM for the modular project:
sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib>
~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
--verbose --echo-mode --module-path . --module
no.smeaworks.movies/no.smeaworks.movies.MoviesApplication

Using the jpackager to package non modular project:
sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT>
~/Downloads/jdk.packager-linux/jpackager create-installer --input lib --output
outputDir --verbose --echo-mode --class
no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar


ECHO-MODE: Running [rpmbuild, --version]

"Adding modules: [] to runtime image."

ECHO-MODE: Running jlink [
--output =
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
--module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
--add-modules = []
--limit-modules = []
--exclude-files = .*\.diz
--strip-native-commands = false
]
/tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException:
jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
for java.base module
Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
them to customize package.
Exception in thread "main" jdk.packager.internal.PackagerException: Error:
Bundler "RPM Bundle" (rpm) failed to produce a bundle.
   at
jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)

   at
jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)

   at jdk.packager/jdk.packager.Main.run(Main.java:71)
   at jdk.packager/jdk.packager.Main.main(Main.java:47)


Is my presumption wrong that it should package also non modular projects,
or am I missing some runtime flags to jpackager?

Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
insight how you use jpackage to build the project? I could not find
anything on it in the Gluon SceneBuilder GitHub repository.

/Sverre

Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos :

> Hi,
>
> As promised, we looked into an interim solution for the packager-gap. Work
> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
> We backported the required changes to an OpenJDK 11 mirror:
> https://github.com/johanvos/openjdk-mobile11/tree/packager
>
> With this, we created modified OpenJDK 11 builds that contain the packager
> (wrapper/exe + module including native library). They can be downloaded and
> tested/used at
>
> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>
> For Windows, you have to unzip the bundle in the same directory as the JDK,
> as the packager wrapper expect to find the java binary at the same level.
>
> Note that these are not products. We use them internally to create
> installers (e.g. we're using them for Scene Builder 11 and that works
> fine), and they do what we expect them to do, but there are no guarantees
> of course so at least for now I recommend using them in development only
> (or even better, look at the changes and contribute to
> https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport)
>
> - Johan
>