Jpackage Icon

[Mei Li Wu]

The jpackage tool will take as input a Java applicationand a Java run-time image, and produce a Java application image thatincludes all the necessary dependencies. It will be able to produce anative package in a platform-specific format, such as an exe on Windowsor a dmg on macOS. Each format must be built on the platform it runs on,there is no cross-platform support. The tool will have options thatallow packaged applications to be customized in various ways.

This module list, along with the main module (if specified) will bepassed to jlink as the --add-module argument. If not specified, eitherjust the main module (if --module is specified), or the default set ofmodules (if --main-jar is specified) are used.

These options are added to, or used to overwrite, the originalcommand line options to build an additional alternative launcher. Themain application launcher will be built from the command line options.Additional alternative launchers can be built using this option, andthis option can be used multiple times to build multiple additionallaunchers.

When i install the program the icon is used for desktop shortcut but in the search toolbar it still displays the default java icon. Is there a way to use the given icon in search toolbar as well? I appreciate any help. thanks!

Before this icon i used a music icon. So in the search the old icon is still in place. So this icon is cached for some reason. Only if i change the app as well as icon then all icons are changed to the new icon. Maybe this is an issue with windows 10. So the issue is now solved.

This icon was used for the installed application but is there a way to create an icon for the installer file itself? The installer file named HelloFX-1.0 doesnt have an icon. Is there a way to configure jpackage to also change icon of this file? Thanks for the help!

Under the hood the jpackage tool uses platform-specific tooling to create the various package types. The customization of the packaging is therefore also very platform-specific and has to be handled individually for each supported platform and package type. However, there are two common features of jpackage that you can use to make this task easier.

The first one is the option --temp some_temp_dir which asks jpackage to copy all scripts and resources needed to create the selected package type into a directory some_temp_dir. These are the scripts and resources that jpackage would use by default.

The second one is the option --resource-dir some_resource_dir which asks jpackage to first look for resources in the directory some_resource_dir and then use its defaults only for the ones it does not find there.

With these two options you can first generate a set of default resources from which you can pick the ones you want to modify and copy them over to the directory some_resource_dir. In a second run of jpackage you can then apply these changes. The most likely changes you can make this way is to exchange the default icons, used by the various package types, with your own ones.

The Icon field in the .desktop file, and the file name of the icon file itself, must match. As per the Icon Naming Specification, the name should be the same as the application's executable program. It should also be installed in the appropriate sizes, in the appropriate hicolor icon theme directory, as per the Icon Theme Specification.

It seems there is a typo in the page you link to, which says to name the icon as desktop.png instead of dungeon.png, and it also only talks about installing the single icon, and in the wrong place. This should be considered a bug in the site itself.

If the icons are in the correct place, and still not showing up, it is likely you need to update the icon cache for theme. You can run sudo gtk-update-icon-cache -f /usr/share/icons/hicolor to update the system hicolor theme directory cache, for example.

To properly install an icon for an application use xdg-icon-resource. The image files must be one of the types: PNG, XPM, or SVG, and the extension must be ".png", ".xpm", or ".svg" (lower case). If a corresponding .icon file exists in the same location as icon-file it will be installed as well.

However between the two calls I cannot see any installer icon to modify within target/jpackage resources dir created. Actually I can't see anything in particular I can sensibly change, I would be interested to know what people have changed for a Windows install.

If you go for a two step process, you create an app-image. Then in the second step start from the app-image and create the installer. The two step process allows you to add/modify the files that will later go into the installer. See -and-runtime-modifications.html#GUID-70F25F63-DE4C-4DC0-83D5-76EB5C55BEF0

I created a .deb package of application by myself and I want to add to it icon and screenshot to visualize it in Application Manager such as Ubuntu Software Center. When I launch my package by double-click. For example, when I launch virtualbox or skype packages their icon and screenshot appear. How can I make this? Is it possible?

Using the Inspector is an easy interface but this moving of your package workaround is required because Inspector cannot see icons not in the Assets folder. As far as I know, the link to your icon will remain once the package is moved.

I'm new to Mac and packaging and signing, but I've come a long way.I've got a Developer ID and a code signing certificate.I want to package a Java app and first of all distribute it from my website, not AppStore.my jpackage call is this:

2)When I've got his running, am I correct in thinking I have to then package the i2Brain.app folder I get? Do I use package for that, or a different tool?3) When I add the following line to my jpackage call, part of the output implies my certificate is ok. See below. So, what is going on? TIA! :-)

Each has their own pros and cons. My only specific advice on this front is that you not use an installer package unless you are installing stuff other than a standalone app. Installer packages are harder to create and, for standalone apps, tend to trigger the spidey sense of advanced users.

For specific advice on how to create these things, see Packaging Mac Software for Distribution. You might also find Creating Distribution-Signed Code for Mac interesting, but it seems like your third-party tools have that part of this problem in hand.

The times when Java was available on almost every desktop are long gone but you can still distribute your desktop applications written in Java in a user friendly way. Since the release of OpenJDK and OpenJFX 9 we can benefit from the JVMs modularization efforts and easily build executables with a bundled JVM trimmed to the needs of our application. In this article we will show you how we ported our small desktop app called PDF Decorator to OpenJDK 11 and used tools like jlink and jpackage to start distributing our app without requiring any third party software on our clients machines.

First of all we must set up our development environment and make sure that we have OpenJDK 11 installed. The best place to get any version of OpenJDK is the AdoptOpenJDK project. Select the OpenJDK 11 with the HotSpot JVM and download the latest release.

PDF Decorator is a small desktop app we developed way back in 2015 for the WALCZAK - wooden floors company to help them adjust their PDF documents to their new visual cooperate identity. We build it using OracleJDK 8 with Gradle and distributed it as a fat jar expecting that the desktops that will run it will have Oracle JVM installed. Today this assumption seams archaic and as PDF Decorator attracted a small user base after being open sourced, we decided to build it using OpenJDK 11 and jlink to change the way we package our app. To accomplish this we had to:

If we run the executable file build/image/bin/PDF Decorator then our application will show up and it will not be using the JVM installed on our system. It will use its own JVM contained in the build/image directory.

Java won't be required on their machines to run it but extracting an archive and finding an executable in it to run is not the most user friendly experience. Providing an installer / package would be much easier for every one. Because of this lets take a look at an upcoming tool developed for Java 14: jpackage.

At the time we are writing this article jpackage is still in development and targets JDK 14. It would be tempting to build our entire app using the upcoming JDK 14 however Gradle will not run on it because of a bug in Groovy. Fortunately our Badass JLink gralde plugin can be configured to use jpackage from JDK 14 even if our project is build using OpenJDK 11. To do this lets download the early access JDK14 with jpackage, extract the archive to a desired location and add an environmental variable BADASS_JLINK_JPACKAGE_HOME pointing to that location. On my Fedora Linux this variable looks like this:

Unfortunately, at the time we are writing this article jpackage struggles to build a working RPM and double clicking on it will cause an error to show in the package manager on Fedora 30. Even after ignoring this error and installing we could not find any way to activate our application in Gnome Shell. I was also not able to uninstall this package due to the following error:

Unfortunately, DEB packages are also not working correctly. After installing the package we could not find any way to activate our application in Gnome Shell. I was also not able to uninstall it due to the same error we noticed on Fedora.

Java is still a good platform for building desktop apps and may sometimes suite your requirements better then browser based technologies that are trending today. Modularization and jlink allows us to ship apps without requiring users to install Java and with the upcoming jpackage tool we will also gain an easy way to build user friendly installers / packages. If you want to examine an application that uses jlink and jpackage in more detail the dive into our PDF Decorators source code.

c80f0f1006