warp VS z-run

jpackage is not the only tool for bundling Java. There is also warp-packer, an open-source tool to create self-contained binary applications from Node.js, .NET Core, and Java. warp-packer requires a similar workflow to Method 2, where you create your modified Java Runtime image and an executable script before bundling everything together into an executable.

https://github.com/dgiagio/warp just googled it, no direct experience

KeenWrite is my free, open-source, cross-platform desktop Markdown text editor developed using JavaFX. The installer script uses warp-packer to create installation-free self-extracting binaries for Windows and Linux.

My desktop text editor[1] is written using JavaFX and leans on Warp Packer[2] to create installer-free, multi-platform executable binaries (without jlink). A user contributed a new dark theme[3], which blends nicely with the desktop.

The JavaFX-based WebView (an HTML rendering component) is lauded, but has no direct API to control the scroll position and is itself a memory hog. Scrolling must be handled through JavaScript, and that indirection is as unwieldy as you can probably imagine. FlyingSaucer is a workable alternative to WebView, but comes with numerous technical issues that rear themselves when embedding a Swing widget inside a JavaFX application---as I discovered during development.

Were I to start from scratch, I would definitely seek out alternative cross-platform programming languages for desktop application development.

[1]: https://github.com/DaveJarvis/keenwrite

[2]: https://github.com/dgiagio/warp

[3]: https://i.ibb.co/QpqS0NS/screenshot.png

"Java -- possible, but you'll need a startup script to just call java -jar some-tool.jar; (also not a good fit for short-lived tools, mainly due to startup times;)"

Two technologies to look at:

* Warp Packer -- https://github.com/dgiagio/warp/

* Liberica Native Image Kit -- https://bell-sw.com/pages/liberica-native-image-kit/

Warp Packer bundles my JavaFX desktop application, KeenWrite into single binary executable files:

* https://github.com/DaveJarvis/keenwrite/releases/download/2.... (Linux)

* https://github.com/DaveJarvis/keenwrite/releases/download/2.... (Windows)

* https://github.com/DaveJarvis/keenwrite/releases/download/2....

The start-up time for the first launch of the .bin or .exe is slow because it unpacks to a user directory. Subsequent starts are fine enough, even when running from the command-line as a short-lived task. Here's the script that creates the self-contained executable files:

https://github.com/DaveJarvis/keenwrite/blob/master/installe...

To create a release for all three files, I run a single shell script from a build machine:

https://github.com/DaveJarvis/keenwrite/blob/master/release....

I could probably generate a binary for MacOS, but not enough people have asked.

I couldn't agree more with you about Ansible... I've started using Ansible in two projects, and I think it was enough for me... Ansible is perhaps great when you have granular tasks, that maybe don't need to communicate between them, or perhaps that don't have too much logic (or worse loops). However, as soon as your Ansible "scripts" start becoming actual "scripts", everything gets out of hand... (Also the performance is terrible due to the fact that each task is "bundled" on the host, copied remotely, extracted, executed, deleted, repeat for each and every instance of the same task...)

----

Now about your `tricorder`, by looking at the readme, I gather it just allows one to run the same command over multiple hosts (filtered by name or tag), but nothing beyond that? How could one run for example a pipeline of tools on the remote hosts? (I assume `bash -c 'tool-1 | tool-2'`, but with careful escaping?)

Perhaps a first step towards actually being an "Ansible replacement" would be to bring back in some "scripting" ability. For example instead of giving each command as arguments, there could be a "library of scripts", and the user can choose one of those to run on each remote host. Then those scripts could be written in whatever language the user chooses (`bash`, Python, Ruby, etc.)

Also, with regard to the "library of scripts", one thing that Ansible got right is the possibility to put multiple different tasks in the same file, thus one doesn't need 20 files for 20 small tasks, but instead these can be put inside the same YAML file.

----

For example this is how I did it in my own "Ansible replacement", <https://github.com/volution/z-run>, like for example, one can write something like these snippets: <https://github.com/volution/z-run/blob/development/examples/...> (see `ssh / launch / simple` that runs locally which just calls `z-run ssh "${_target}" ':: ssh / remote / main' "${@}"`, which is in itself a non trivial `bash` script, one that will run remotely.)

In the end, what I think we need, is a tool to easily run "scripts" on a remote system, but make it as easy to use as it would be on the local machine. (Sort of like the RPC but across SSH and for scripts.)

Good point!

I'll add to that READMEs, LICENSEs, SBOMs (Software Bill of Materials), example configuration files, etc. How to supply all those files when all one gets is a single binary executable?

Simple! Bundle everything in the executable.

As a bonus, because the tool outputs these files, it can now generated them dynamically. For example instead of a bland configuration file, with all the possible integrations commented out, it could either try to auto-detect where it's running and what's available, or present the user with a question-answer session to fill in the details.

----

For example, a pet project of mine <https://github.com/volution/z-run>:

z-run --readme # shows the README with `less` (if on TTY) or to `stdout`

z-run --readme-html # for the HTML version to be opened in `lynx`

z-run --manual # or --manual-man or --manual-html

z-run --sbom # or --sbom-json or --sbom-html

It even gives you the source code:

z-run --sources-cpio | cpio -t

So, does your tool need a `.desktop` file? Just create a flag for that.

Or, if there are too many such extra files needed to be placed wherever provide an `--extras-cpio` and dump them as an archive, or if placing them requires some work, provide an `--extras-install`, but before `sudo`, kindly ask the user for permission.

Granted all this requires some extra work, and increases the bulkiness of the executable, but:

* all that extra code can be extracted into a common library; (I intend to do that for my software;)

* if all these are compressed, especially being text-only, they are a fraction of the final executable;

----

I am especially proud of the `--sources-cpio` option. Is something broken with a particular version of the tool that you rely on? Great, instead of bumbling around GitHub to find the particular commit that was used to build this particular version, I can just get the sources from my tool and use those. All I need is the build tools, which in case of Go is another `.tar.gz`.