Further improvements for DesktopAppLauncher

[HenrikJannsen]

The app launcher concept was discussed here https://github.com/bisq-network/bisq2/issues/200:

It is partly implemented via: https://github.com/bisq-network/bisq2/pull/1028 https://github.com/bisq-network/bisq2/pull/1029 https://github.com/bisq-network/bisq2/pull/1030

Description of concept:

We added a DesktopAppLauncher module which will be used for the creation of the installer binaries. It has a dependency to the DesktopApp module, the normal desktop JavaFX application (and the one used for dev testing).

We ship the shadow jar of the current version with the DesktopAppLauncher. The JRE is part as well of the binary.

At startup, it looks up if there is a version file in the data directory. If so, it reads it and look up if there is a jar file in the expected directory inside the data dir. If so, it verifies the signature of the jar file with the provided pubKeys and if valid, it starts a new process with that jar file. If there is no version/jar file the DesktopApp.main method is called.

When an update notification is sent to the P2P network the user gets a popup with the option to download and verify the new version (shadow jar of DesktopApp). After the download and a restart the DesktopAppLauncher does the above described check again and starts the new jar in a new process instead of calling the DesktopApp.main method of the version shipped with the app launcher.

Further improvements:

• Optimize desktop shadow jar file to make it smaller (currently it contains test libs as well)
• Make the jar file deterministic (strip dates from metadata files)
• Extract binaries shipped in the resources (tor, electrum,...) into another jar file
• Extract 3rd party libs
• Extract those parts which rarely change into another jar file
• Add management of those additional jars (build, apply class path, download and verification, signature creation)
• Consider to delete old jars after new ones are applied

In case we manage that the jars which change with each version are relatively small (< 20 MB) we can consider to distribute those via the P2P network. Otherwise we can consider to add a tor hidden service for download to remove dependency to the Github download page.

[HenrikJannsen]

One downside of the current implementation is that the launched jar file runs as a java app. The OS notifications (on OSX) show luckily the Bisq icon, but the app appears as Java app.

I leave it for now as the topic is a bit of a rabbit hole.

Here a list of related projects: https://jreleaser.org/ https://github.com/shannah/jdeploy https://github.com/vinumeris/updatefx https://www.hydraulic.dev/ https://www.ej-technologies.com/products/install4j/overview.html https://sparkle-project.org/ https://gluonhq.com

[HenrikJannsen]

Found another solution (inspired from how UpdateFx is doing it) to load the main app from the jar file in the launcher app. Implemented in https://github.com/bisq-network/bisq2/pull/1039 This fixes the problem described above.

[HenrikJannsen]

As far I am aware @alvasw is working on a different implementation of the Updater