What tools are required on the final user machine to make jdeploy work?

[salmonb]

I'm interested to have an answer in general, but also in particular for CLI tools.

Will the final users need node.js if I publish with jdeploy?

[shannah]

No tools are required on the user machine for gui apps.

CLI apps currently are only installable via npm so node is needed there. At some point i will revisit cli apps to remove this dependency.

I have been focusing mostly on the gui desktop experience for the past while.

[salmonb]

I'm happy to hear that you have a plan to remove the dependency to node/npm for cli apps as well.

I'm looking forward to seeing your solution.

Thanks for all your work on jdeploy

[salmonb]

Just checking if you made any progress on removing the dependency to node for cli apps?

[shannah]

Not yet. But with ARM support out of the way, I should have time to revisit this soon.

[shannah]

Just checking if you made any progress on removing the dependency to node for cli apps?

@salmonb I have been playing with the launcher to support both service and cli apps. service apps are basically the same as cli apps except they can integrate with the native service manager to install, stop, start, etc...

I can think of a lot of fun ways to use these features but i'm curious what use cases you are interested in?

eg i could produce simple binaries that you can run that know how to install and update themselves, and know how to integrate into the native service managers.

i could also make a "copy curl snippet to install" like i have already for the gui apps, except make it cli based.

I've also thought about using this to deploy desktop "service" based apps that include gui management (eg taskbar menus to start stop, configure).

But i'm curious what use cases others have.

[salmonb]

Sorry for the delay, I was unavailable during the last 2 weeks.

I'm the author of WebFX (you previously asked about the TeaVM support btw and I'm currently working on it fyi). I would also like to find a better way to distribute the webfx cli (an essential tool for developers building webfx apps).

The way to install it right now is explained here. Basically developers have to clone the repo on github and build it with Maven, then create a shortcut to it to finally get the webfx command in the terminal. The tool can update itself with webfx bump cli which basically does a git pull and a maven rebuild. It's not very elegant, but at least it relies on tools that they very likely already have: JDK, Maven & git (as I'm targeting Java(FX) developers).

What would be their experience if I was using jdeploy instead? How would they install it? and get updates?

Thanks

[shannah]

What would be their experience if I was using jdeploy instead? How would they install it? and get updates?
Let me put this question back to you, as "what would be their ideal experience".

There are a few piece that I could provide.

For installation we could have one or both of:

1. Desktop (gui) installer that adds the cli command to the PATH
2. CLI installer that they run by pasting a snippet like /bin/bash -c "$(curl -fsSL https://www.jdeploy.com/~webfx/install.sh)" into their terminal.

For updates, the binary knows how to update itself. For CLI we probably don't want it auto-checking for updates on every run, so we'd probably have the trigger it with something like "webfx update".

I have an initial implementation of both "cli" apps and "service" apps. Sounds like the webfx case is "cli" - not service.

One aspect on the update that I'm torn on is how best to trigger the update. If I have the launcher check for the "update" command, then it may confict with your CLI app's args, if your app also has an "update" arg. For my initial implementation I resolve this by making the command look for the jdeploy args first, and then the -- arg marks the end of jdeploy args and the beginning of the cli command's args.

e.g. To run your app's you would have to do webfx -- arg1 arg2 arg3.

[salmonb]

I think the bash snippet is good enough for the install (option 2).
Does it set the shortcut command, i.e., can they type "webfx" commands straightaway after that?

The cli is used quite often in webfx dev. So having to insert -- on every command is annoying.

Can it be the other way around, i.e., the commands go first to webfx and a specific command calls your script back for the update?

If not possible, can you remove the -- and if the first arg doesn't mean anything to jdeploy, then it assumes it's a webfx command and pass all args to it?

[shannah]

@salmonb I'm edging in on a solution that I think may work well for WebFX. I've added support for "commands" to be installed with jDeploy apps. A command is just a CLI wrapper that runs your app as a CLI app. The installer and "main" app are still intended to be a desktop app, but you can define commands that will be added to the PATH, and can be configured to run your app with specific arguments, and pass through user args.

The commands themselves don't trigger auto-update. They just work with whatever version is installed. You can detect when it is being launched GUI, and just show some basic placeholder text with some info about webfx.

So the flow would be:

1. user downloads and runs desktop installer.
2. The desktop installer allows the user to specify their auto-update preferences (default is to always update to the latest).
3. The installer installs the desktop app (openable in Start manu/Applications menu/Dock etc...), as well as adds the webfx command to your PATH.
4. Whenever the user launches the desktop app, it auto-updates according to the user's auto-update settings.
5. webfx is available in your PATH.

I plan to add support for the more CLI-centric flow where the installer is pure CLI, but I'm going the way of adding support for "companion" commands first as this fits better with some other use cases I have (e.g. making it easy to make apps "scriptable" via MCP).

I'll create a fork of the webfx-cli to demonstrate how this works.

[salmonb]

Great news!

I'm looking forward to seeing a working prototype.

FYI it's important that the CLI is installable on servers too, for example to be used in a GitHub workflow. But I guess this is part of the plan in your second step.

Thank you for your work on this! 🙏