Re: jpackage EA Build 0

When there is a --files arg this works as expected, all jars are added to the classpath in the config file. When there is no --files arg, only the jar files at the top level of the input dir are added to the classpath in the config file. I filed  bug JDK-8215900

Re: jpackage EA Build 0

If the main jar is in a subfolder the .cfg file is written incorrectly leading to: Error: Could not find or load main class Caused by: java.lang.ClassNotFoundException: Which I only found by manually running: ./MyApp.app/Contents/MacOS/MyApp as double clicking doesn’t seem to show

Re: jpackage EA Build 0

On 12/17/2018 12:45 PM, Scott Palmer wrote: I finally got to the point where I can play with this… I’m just using trial and error, trying to figure out what to do based on the output of package --help and responding to error messages to guide me. I’ve already used jlink to create a

Re: jpackage EA Build 0

I finally got to the point where I can play with this… I’m just using trial and error, trying to figure out what to do based on the output of package --help and responding to error messages to guide me. I’ve already used jlink to create a runtime (including JavaFX) that I want to use with my

Re: jpackage EA Build 0

Building a non-modular app on macOS: In the output folder I find a .dmg file and a .pkg file. However, the .dmg produced contains both the application bundle AND the .pkg installer. It should not contain the .pkg Scott > On Dec 14, 2018, at 7:46 AM, Andy Herrick wrote: > > I am pleased to

Re: jpackage EA Build 0

One more thing discovered: Even though the version is defined in DEB control file, the deb bundler does not use it for the deb file name. The RPM bundler does it right. It uses the version and release specified in the RPM spec file. application-1.0-deb application-1.2.3-rc1.rpm A workaround is to

Re: jpackage EA Build 0

I have discovered a bug with the jpackage created application image. It does not pass any --arguments to the application. The application.cfg contains the arguments, but the native binary does not pass them to the application. [ArgOptions] --laf=nimbus --test1=value1 --test2=value2

Re: jpackage EA Build 0

Den søn. 16. des. 2018 kl. 19:32 skrev Andy Herrick : > > > On 12/15/2018 12:44 PM, Andy Herrick wrote: > While investigating this, I found undocumented functionality left over > from JavaFXPackager that may be the root of these class-path messages. > > This is both dangerous and powerful, and

Re: jpackage EA Build 0

On 12/15/2018 12:44 PM, Andy Herrick wrote: I have yet to find out how to specify the bundle resources. It tells to put them on the class path, but that cannot be right, as jpackage is module. Using default package resource [menu icon]  (add package/movies.png to the class path to

Re: jpackage EA Build 0

Den søn. 16. des. 2018 kl. 14:27 skrev Andy Herrick : > > The result of JDK-8213392 was not that there was any problem creating > the package, but that the packaged app would not run, because the > modules from the --module-path arg are never included in the packaged > app, or referenced in the vm

Re: jpackage EA Build 0

On 12/15/2018 2:48 PM, Sverre Moe wrote: Den lør. 15. des. 2018 kl. 18:44 skrev Andy Herrick : On 12/15/2018 11:26 AM, Sverre Moe wrote: Some feedback from using this new JDK12 jpackage. I have yet to find out how to specify the bundle resources. It tells to put them on the class path,

Re: jpackage EA Build 0

Den lør. 15. des. 2018 kl. 18:44 skrev Andy Herrick : > > > On 12/15/2018 11:26 AM, Sverre Moe wrote: > > Some feedback from using this new JDK12 jpackage. > > I have yet to find out how to specify the bundle resources. It tells to put > them on the class path, but that cannot be right, as

Re: jpackage EA Build 0

On 12/15/2018 11:26 AM, Sverre Moe wrote: Some feedback from using this new JDK12 jpackage. The argument --version is no longer used for setting the bundler version. Thus one needs to specify bundle resources (spec for RPM and control for DEB), if the version is anything other than "1.0".

Re: jpackage EA Build 0

Noticed now that there was an --app-version argument as replacement for the previous --version. Though I would like to see any examples during help how to specify the bundle resources to class path. /Sverre Den lør. 15. des. 2018 kl. 17:26 skrev Sverre Moe : > Some feedback from using this new

Re: jpackage EA Build 0

Some feedback from using this new JDK12 jpackage. The argument --version is no longer used for setting the bundler version. Thus one needs to specify bundle resources (spec for RPM and control for DEB), if the version is anything other than "1.0". I have yet to find out how to specify the bundle

Re: jpackage EA Build 0

> On Dec 14, 2018, at 12:05 PM, Phil Race wrote: > > See Kevin's last reply. > > -phil. > > On 12/14/18 10:03 AM, Michael Hall wrote: >> OK fair enough, got that. This just made me wonder though, would JDK 12 be >> the only JRE that can be targeted for packaging? >> It can only make JDK 12

Re: jpackage EA Build 0

See Kevin's last reply. -phil. On 12/14/18 10:03 AM, Michael Hall wrote: OK fair enough, got that. This just made me wonder though, would JDK 12 be the only JRE that can be targeted for packaging? It can only make JDK 12 executables?

Re: jpackage EA Build 0

On 12/14/2018 10:03 AM, Michael Hall wrote: On Dec 14, 2018, at 11:58 AM, Phil Race wrote: "Incomplete" meant "JDK 12 is not yet completed". Perhaps that could have been worded differently like "a non-final version of JDK12". I think the intent was to make it clear what JDK version this

Re: jpackage EA Build 0

> On Dec 14, 2018, at 11:58 AM, Phil Race wrote: > > "Incomplete" meant "JDK 12 is not yet completed". > Perhaps that could have been worded differently like "a non-final version of > JDK12". > I think the intent was to make it clear what JDK version this was. Eg it is > not built on top >

Re: jpackage EA Build 0

"Incomplete" meant "JDK 12 is not yet completed". Perhaps that could have been worded differently like "a non-final version of JDK12". I think the intent was to make it clear what JDK version this was. Eg it is not built on top of 11 GA. It is built on top of the current JDK development branch

Re: jpackage EA Build 0

> On Dec 14, 2018, at 11:53 AM, Kevin Rushforth > wrote: > > > So I could say drop the jpackage command into my app’s current earlier JRE > > bin directory and it might work? > > No. You need to run jpackage from the JDK 12 ea build that you downloaded. > jpackage isn't something you drop

Re: jpackage EA Build 0

> So I could say drop the jpackage command into my app’s current earlier JRE bin directory and it might work? No. You need to run jpackage from the JDK 12 ea build that you downloaded. jpackage isn't something you drop into your application, it's a tool you run to package up your application

Re: jpackage EA Build 0

> On Dec 14, 2018, at 11:30 AM, Kevin Rushforth > wrote: > > Correct. jpackage will be delivered as a tool that is part of the JDK. Future > EA builds will likely include an EA of JDK 13. > > -- Kevin > > On 12/14/2018 9:26 AM, Michael Hall wrote: >>> Warning: This build is based on an

Re: jpackage EA Build 0

Correct. jpackage will be delivered as a tool that is part of the JDK. Future EA builds will likely include an EA of JDK 13. -- Kevin On 12/14/2018 9:26 AM, Michael Hall wrote: Warning: This build is based on an incomplete version of JDK 12 . So

Re: jpackage EA Build 0

> > Warning: This build is based on an incomplete version of JDK 12 > . > So when I download (OS X) it appears it is included with a entire jdk 12 build?