Open marius-m opened 6 years ago
I guess if you're generating a completely bundled application, I wonder what the value is in using Getdown at all. If Java is hidden inside what looks like a platform-specific executable, then you can use whatever auto-updating systems are available for the target platform.
This might actually be a smarter way to deploy Java applications in this modern world of app stores and OSes that lock down software installation, or at least make it really hard.
Getdown harks from an age where it was viable to have a simple installer that plopped a JVM and an auto-updating stub somewhere on a user's machine, and then the app could just "update itself" in a cross-platform way. But it is increasingly difficult to install or update software across OSes by just downloading and changing files. And if your app is not just a collection of jar files + a JRE, then it fits less into Getdown's model as well.
This is not to explicitly discourage you, just to point out that if we change Getdown to allow the running of an arbitrary "executable" instead of running a JVM on some jar files, then it starts to beg the question of why Getdown is involved at all.
That said, we probably should change Getdown to allow the running of an arbitrary executable. Then it could just run whatever the launcher stub is that is provided by the packer, and if the app itself is still comprised of jar files, then Getdown can still update those as they change using its primitive "change files on the file system" approach, and hopefully the launcher is small or doesn't change so that whatever hurdles need to be cleared for installing an executable into the OS can be done the first time the app is installed.
Is there a simple example of a bundled JavaFX app somewhere that I can clone and build so that I can play around with changing Getdown to enable running such apps?
I managed to build the example apps of javafx-gradle-plugin and had a look at the sort of app layout that the generate.
It really ends up looking like the sort of situation where using Getdown as a library rather than a launcher would be vastly preferable. That way, your app is launched via the native shim and the desired JRE is used, and then your app could just use Getdown to manage the upgrading of its jar files and any other resource files that live in the Contents/Java directory (on the Mac anyway, presumably the jar files and additional resources go in a single directory, perhaps with a different name, on Windows and Linux).
This would require more coordination from the app. It would require Getdown to download updated files into a staging directory (which it already supports), and then relaunching the app in "install mode" where it would install the updated files over the old files before the JVM started using them (only necessary on Windows, but still a good approach), and then Getdown would invoke your app's entry point.
I think some people already use Getdown like this, even though it's not exactly what it was designed for. All the necessary parts are there, you just have to bundle getdown.jar with your app and call into the code in the right places. Maybe someone who has done it can create an example app that shows how such a thing would work. If this sounds like something you want to try, you could try posting to the Getdown mailing list asking there for pointers from anyone who has taken this approach. I definitely remember at least one person on the list talking about it.
Sorry for a very late reply. Amazing write down, thank you so much for the effort. After quite a while, I wanted to do a one more jab at this, so I'll try it out. If It'll work, maybe it would be a good idea to write dome some kind of tutorial about, how to launch this.
I managed to build the example apps of javafx-gradle-plugin and had a look at the sort of app layout that the generate.
It really ends up looking like the sort of situation where using Getdown as a library rather than a launcher would be vastly preferable. That way, your app is launched via the native shim and the desired JRE is used, and then your app could just use Getdown to manage the upgrading of its jar files and any other resource files that live in the Contents/Java directory (on the Mac anyway, presumably the jar files and additional resources go in a single directory, perhaps with a different name, on Windows and Linux).
This would require more coordination from the app. It would require Getdown to download updated files into a staging directory (which it already supports), and then relaunching the app in "install mode" where it would install the updated files over the old files before the JVM started using them (only necessary on Windows, but still a good approach), and then Getdown would invoke your app's entry point.
I think some people already use Getdown like this, even though it's not exactly what it was designed for. All the necessary parts are there, you just have to bundle getdown.jar with your app and call into the code in the right places. Maybe someone who has done it can create an example app that shows how such a thing would work. If this sounds like something you want to try, you could try posting to the Getdown mailing list asking there for pointers from anyone who has taken this approach. I definitely remember at least one person on the list talking about it.
I agree that using something like microsoft store or whatever is a much stress free and better choice. But what if I don't have a publisher account, where do I do it for free then?
Getdown isn't exactly what I'm looking for, but its the only alternative I could find. If you know any other way I could do this for free, let me know
Hi,
I'm using
GetDown
to launch a simple JavaFx bundled application, but seems like with changes in recent bundling, CLI tools are not published any more when bundling application with built in JRE. Is there any way to launch an application without or run the app with some "trick" without the cli tools ?I'm using
javafx-gradle-plugin
(https://github.com/FibreFoX/javafx-gradle-plugin) in which in turn usesfxpackager
(i think) to bundle JRE inside the native app bundle.Same thing applies to mac, linux so i assume this has changed in recent time as i've had no problem bundling app before.
Source where the bundled app is being stripped from CLI tools: https://github.com/teamfx/openjfx-8u-dev-rt/blob/master/modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java#L990
Platform:
Mac 10.13.4
Java:1.8.0_172