You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* What went wrong:
Execution failed for task ':MyProject:jfxNative'.
> No bundler found for given name image. Please check your configuration.
However help output of javapackager indicates:
-native
generate self-contained application bundles (if possible).
If type is specified then only bundle of this type is created.
List of supported types includes: installer, image, exe, msi, dmg, rpm, deb.
and sure enough 'image' is accepted on the command line
The text was updated successfully, but these errors were encountered:
Yes, this was intentionally. In previous versions of the JDK 8 there seemed to be no further use of that filtering-type, and I personally find it better to have tighter control about the generated files than "just anything possible".
I think so. "image" doesn't mean "just anything possible". That's what not specifying any bundler means. "image" however, creates the application bundle with the java launcher, .cfg files, app folder, runtime folder, etc., and then I can incorporate those files into a custom installer.
The problem with this is, that you have no real control about what bundler will get used. This is kind of a bundler-group-name, where NONE and ALL had special meaning. Looking at the JDK 10 this still seems to be existing, but the whole concept feels broken for me.
When I set
I get:
However help output of javapackager indicates:
and sure enough 'image' is accepted on the command line
The text was updated successfully, but these errors were encountered: