This is a passion project of mine to make it easier to deploy Java desktop apps. I'm very happy with the result, as IMO, the process is orders of magnitudes simpler than what we had before. Some features include:
- Native installers for Mac, Windows, and Linux
- Build native bundles for all platforms from any platform (e.g. You don't need Mac to make a Mac app. You don't need Windows to make a Windows app, etc..)
- Auto updates. Your users automatically get the latest version on each launch
- Small installer bundle size (3mb compressed)
- No need to futz with Mac codesigning/notarization
- Instant download page so your users can download your app as soon as its published.
- Free, open source
Please take it for a spin, and let me know what you think.
Nice to see some freshness pushed into the officially dead model of sharing a JRE between applications instead of going through the pains of the jlink route which seems a bit heavy for many use cases.
Assuming I'd rather self-host instead of hitching a ride on npm - could it it still be useful, as a cross-platform bundle maker? What are the single points of failure for the curated JRE procurement? Is it npm, is it jdeploy, is it adoptium? All of them?
I've done dances like concatenating a zip to a pre-built nsis exe to get a windows installer from a Linux build server, jdeploy sounds like an interesting alternative!
> Assuming I'd rather self-host instead of hitching a ride on npm - could it it still be useful, as a cross-platform bundle maker?
I've seen some interest for self hosting, so it will likely be added. In an earlier iteration (I've been at this for a couple years), it was self hosted, but I found that npm brought a lot to the table and simplified things, so I focused on that.
> What are the single points of failure for the curated JRE procurement?
Here's the process. The launcher (written in C and Go) checks the npm registry to get the app's metadata (e.g. JVM requirements, versions, etc..). If the app needs to be updated, it will update it. If it needs to download a compatible JVM it downloads it. (But it reuses JVMs so if it already has one that meets requirements, it will use that). Currently it downloads from Azul. Used to use Adoptium but switched for JavaFX support reasons.
Any of these pieces could be switched out pretty easily (npm -> self hosting, Zulu -> Adoptium, or self hosted, bundled VM, etc..).
Side note / shout out to Azul for being just great. Their technical support (even while just evaluating Zing) has been excellent and their free Zulu offering is a breeze to install (Debian here).
Interesting project. We build and maintain a significant cross-platform JavaFX app, and use a combination of JLink (to create a smaller executable with bundled JRE), install4j (for the native .app/.exe wrapper) and Packages (macOS)/InnoSetup (Windows) for the installer. The installer has a non-trivial amount of scripting under the hood so being able to customize that is really important, at least for us.
I wonder if you won't run into trouble because of the Mac codesigning/notarization though. I think this poses a significant legal risk to you, as you are now distributing potentially malicious software signed with your certificate. Also I'm pretty certain Apple doesn't like this "code signing as a service" approach.
Is the lack of notarization truly an issue? Aside from demonstrating that the creator has a paid subscription to the developer program, what does notarization accomplish that isn't already handled by XProtect (i.e. a YARA scan) and the Malware Removal Tool (MRT)?
Are there any examples anywhere of malware that has slipped through the client-side XProtect pre-flight checks, but that the server-side notarization checks have caught? Most independent macOS security literature I've read implies that notarization and code-signing is more about retaining centralized control of the app distribution process, but does not actually contribute anything to the malware mitigation tools that have been built into macOS for a very long time.
Customers don’t want notarization prompts for their expensive, custom-built software packages…
So even if the security benefit is negligible (I agree), if you want to play, you have to play by their rules.
As someone who's had to recently setup jpackage for one of my side projects, which took forever and a day and I'm still not happy with the result. I'm very interested.
Just glancing at the site, it really looks like this is something you put a bunch of effort into. I'll definitely check this out! So thanks.
The launcher gets the package's metadata from npm's registry on launch. This will tell it the latest version, and also the JVM requirements (e.g. version, javafx, jdk, etc..). It compares this with what it has installed. If it doesn't have the latest version, it will download it. If it already has a JVM that meets the requirements, it uses it. If not, it downloads one from Azul.
When it downloads a new version, it doesn't overwrite old versions. You can have two versions installed simultaneously. They are kept in $HOME/.jdeploy/packages/YOUR-PACKAGE/VERSION
It is also possible to peg your app to a particular version so that it doesn't auto update. Other variations are possible too, such as only autoupdating minor updates. E.g. Update to 2.1 or 2.2, but not to 3.0. For simplicity, I haven't exposes some of that yet.
There are no hooks. When your app runs, it is always running a particular version of the app. If your app needs to "transition" its resources when new versions are run, then that is up to you. No different than if the user downloaded and updated your app manually.
> Interesting idea, though I thought the orig. goal of Java was to avoid this in the first place.
IMO this is moving back in the direction of the original WORA philosophy of Java. jDeploy is designed to be cross platform. No platform-specific build settings, to as much extent possible. After the death of Applets and WebStart, the new direction of bundle a JRE with every app - and rely on platform-specific 3rd-part tools to create the bundles never felt right to me.
I have reproduced this issue, and have posted and update that should fix it. Please try downloading either of the demos again and let me know if it still gives you issues.
I have received a few reports on Linux. I'm working on it. Literally this is the reason why jDeploy is helpful. I've spent 2 years working out many details. Every OS/Version/distribution has needed some special care. Up to now I've been working with a single Ubuntu 20 box for my linux testing. Today, in response to these reports, I'm setting up a number of Linux VMs to test other variations to get to the bottom of this. I should have these issues resolved shortly.
In my opinion, JavaFX is the Duke Nukem Forever of UI toolkits. It was supposed to be a "modern" replacement for Swing, ultimately blooming into a full-featured, rich GUI library. But it's now almost 15 years since JavaFX was introduced, and Swing is still much more capable and flexible. I would pick Swing over JavaFX in a heartbeat for a new app right now.
I haven't seemed to be running into any problems ... yet ... with JavaFX maven dependencies. It pretty much Just Works(tm).
A single main dependency (org.openjfx/javafx-control) and a plugin (org.openjfx/javafx-maven-plugin) and you're off to the races. I don't install JFX into the JDK at all (not even sure, honestly, if that's still a thing).
I have more problems with JDK 9 modules (which modern JavaFX seems to support, but good luck with much of anything else of size).
Since I am pretty much awful at GUI programming, I've made a lot more progress with FX on my home projects than Swing. It's no panacea, but it's been working for me.
> figure out dependencies or how to fit JavaFX into maven/gradle.
I struggle with the same thing. jDeploy solves one half of that (deploying javafx is no longer a struggle). I think there is still room to make creating new projects simpler.
Don't do that, use a JVM that includes JavaFX, as this project seems to do.
If you use SDKMAN, there are a couple of vendors, including Zulu, that distribute the latest JDKs with JavaFX included.
> What Java framework(Swing, FX etc) would you recommend for a desktop Java app?
Up to you. Swing is old faithful. JavaFX will result in something that is "cooler" and more modern. Both are supported. If you select "JavaFX" in JRE requirements, it will automatically use a VM with JavaFX to run your app so there's no penalty in app size for using JavaFX.
If you are looking to target mobile, and also want to deploy to Desktop, you might want to check out Codename One. (Full disclosure: I work there).
JavaFX and Swing aren't the only games in town either. jDeploy is part of my desire to make Java a more compelling choice for desktop app development. I still think it is too complex and overwhelming for new comers who just want to make a desktop app. I have some thoughts on how to simplify this, but I'll save that for another thread.
I was thinking that this combo can really change the native desktop development landscape, it's still too early to tell but if you can solve development speed, performance, looking good and easy deployment in one stack it would really improve over Electron based apps.
I agree. Once you fight through the initial project setup, and solve the deployment difficulties (jDeploy), Java is a remarkably good platform for Desktop development. The sheer number of libraries available to you with a simple copy/paste dependency snippet, is unrivalled in any other ecosystem.
It is exciting but even less there than JavaFX unfortunately. That's the problem with most UI systems, they evolve really fast in the beginning and show great promises, then the real difficulties arise and you have users that start to want a stable API.
The thing is that Compose is becoming the de facto UI toolkit for Android, and there is A LOT of really smart people working on it (both at Google and Jetbrains).
Maybe I'm over-hyping it, but I really doubt there has been a UI toolkit with that much work behind in a long time (Maybe Cocoa and one of the last 3 iterations of UI toolkit on Windows had that many work hours, but Cocoa does not work in all OS and the Windows ones well ... :shrug:)
Arguably, Flutter has had even more work done... it's incredible how Flutter tools work so beautifully on all OS's.
I've played with Compose for Desktop and it's basically the Android framework, but running on desktop, as you might expect... but the tooling is currently not anywhere as good as Flutter IMO... and the customizations to make apps look like actual desktop apps (rather than mobile apps on Desktop which is just horrible) is currently impossible because there's just no docs on how to do it or any library that helps achieve that that I could find... Flutter, on the other hand, has multiple "themes" that work well on Desktop... I was amazed to watch a YT video where a Flutter guy showed how he implemented a Windows 3.1- like theme for Flutter and re-created a really old app for a customer that, for users, looks just like the old one (which was a strong requirement by the customer!).
FWIW, there's JetBrains's JetBrainsRuntime project [1] containing Swing patches for eg HiDPI support and other things. Haven't worked with it, nor do I have a stake in it; just mentioning it because JetBrain are one of the few companies delivering kick-ass, commercially successful, mainstream desktop software using Java/Swing today.
Is there a reason these are not getting backported to OpenJDK? I know that jetbrains do contribute a bit, but I feel like their model of having way out of date jdks shipped (offering worse performance then available) is not a good one. (They just recently switched to 11, and was still using the old concurrentms GC, over which G1 runs circles, let alone ZGC)
It is absolutely awful by default; IntelliJ apps are slow to the point of being unusable out of the box. The good news is that it is easily fixed (at least for my use case). I have tinkered a bit and running them on JDK16 or later, with JATOC has been a life-saver for me the past year, and reduced my paying subscription to an act of charity.
"Develop with pleasure" is well and truly dead until they make the out-of-box experience FAST.
What are you comparing against? VSCode with a ton of plugins to almost match IntelliJ? Because that's a lot slower than IntelliJ in my experience, not even close...
I am currently using IntelliJ heavily at work and I would agree it was too slow for a gigantic project we have... but there's literally no alternatives that work nearly as great (Eclipse, Emacs, VSCode, tried them all, they mostly can't even load a project like ours --- Eclipse can but it's a pain to index everything on re-builds)... but since I got a Mac M1 Pro, IntelliJ again feels light and snappy :D unfortunately, having the best hardware possible seems necessary now, as ever.
my expectation is that a 64GB 8 core Intel(R) Xeon(R) CPU E3-1230 v5 @ 3.40GHz with NVMe disk and nvidia graphics on the latest Debian should be much faster running PyCharm than it is in reality.
I develop on mid 2014 15" MacBook Pro mid with 16GB of RAM and 150k LOC Java project works quite ok with latest Idea. It probably depends on what expectations are. It's hardly comparable experience to what was available 10-20 years ago.
Nice work and good explanatory website. I would like an easier process for deploying Java desktop apps, but the solution I use would need to also make it easier for me to deploy to the app stores (aka Mac App Store, Microsoft Store on Windows). Basically I would need a code signed app that I could submit to Apple.
jDeploy can be configured to produce an app like this, where everything is bundled together. It will even automate the codesign and notarize process. However, to do this requires a Mac, and you still need to jump through all Apple's crap for certificates etc... I haven't documented this process officially because I didn't want to confuse the primary message.
For app store builds, jpackage is probably the way to go.
A bugbear of mine having to use a couple of Java apps on my Mac is the non native window support.
Do JBundle'd apps support native full screen size (not just expanding to fill the size of the screen, which allows other app windows to appear in front/behind), and native keyboard shortcut behaviour?
This is more of a GUI concern, and I wouldn't expect a bundler like JDeploy to be able to do something about this.
An appropriate GUI toolkit should be able to integrate with the native fullscreen.
I briefly used the webview for java library [1] and it does the right thing because the browser handles it. JavaFX also supports [2] native fullscreen if appropriate integration is used. Not sure about Swing/AWT etc.
> It was a little odd that the new download had the same version number as the old
The build number refers to your app version. The download page creates the bundle on the fly (but does cache) using the latest jDeploy release, so when I released the new version of jDeploy, the bundles in the download page are auto-updated. I thought of adding the jdeploy version number into the installer name, but it was getting pretty busy already, so I decided to just leave that off.
This is so nice - it solves the biggest problem of Java desktop deployment in a very elegant way! I have wasted so much time figuring out native app packaging and code signing (not to mention figuring it out on different platforms). I was able to get this to work in about 30 minutes.
You are a hero - I hope this project really takes off! I dare say this is even better than Java Web Start (before it became hopelessly broken).
This looks extremely scary to me, they say you can avoid having to noterize your apps with apple and microsoft because their installers are already approved. What happens when someone publishes some malware application using their wrapped and noterized installer? Apple and microsoft will then flag all other applications that used jdeploy as malware as well since they are all relying on the same noterized installer application.
Super risky and definitely not a good approach from a security perspective.
I considered that. The approach I'm taking was inspired by the way that Chrome creates app bundles for PWAs.
> What happens when someone publishes some malware application using their wrapped and noterized installer
The installer application simply installs the app. It doesn't in itself run any of the app's code. The installed app doesn't need to be codesigned and notarized like it would if you had just downloaded it from in your web browser.
This works fine for many cases. A limitation is that apps built in this way can't be submitted to the app store. For that you would use jpackage or similar. But in most cases, this strategy is fine - and even better since it includes things like auto-updates.
>The installer application simply installs the app. It doesn't in itself run any of the app's code. The installed app doesn't need to be codesigned and notarized
Wait, then doesn't that mean Apple's intent there is broken? I mean if you can bypass its controls on installing unsigned apps by merely wrapping an unsigned (possibly malicious) app in a signed installer, then what's the point?
Very naive question but is it different from what npm, pip, etc. let you do already? Does the app installed this way get more permissions coming from a signed installer? I'm not familiar with OSX security model.
> Very naive question but is it different from what npm, pip, etc. let you do already?
npm, pip, etc.. are CLI install tools. jDeploy supports CLI app distribution using npm also. But the key difference is that jDeploy provides double-clickable installers for the apps. If you're distributing a desktop app, it should be installable in the desktop (IMO). Making users go to the command-line to install the app is actually prohibitive for the average user. Even when your userbase is programmers, I find that making them go into the command-line loses them.
> Does the app installed this way get more permissions coming from a signed installer? I'm not familiar with OSX security model.
Since Catalina, you can't download and run a Mac app in any form unless it is signed and notarized. Using the signed and notarized installer allows you to get around this limitation.
In addition Java is signed. So the app is running within a signed/trusted VM that has the right permissions. The OS includes guards in place (at least in Mac) so permissions should be granted if you do something outside of what you're supposed to do.
It definitely bypasses signature checks on macOS and Windows. I don't know if that's actually a bad thing for security, though. Notarization and code signing has hardly posed a problem for malware on either platform so far.
I use jpackage to build native bundles for JOSM, an editor for the OpenStreetMap project. As others have pointed out, one of the biggest shortcomings is that you have to use a Mac to build a Mac bundle, etc.
You might want to consider spelling codesigning as two separate words. The meaning / interpretation “co-designing” might be more prevalent for some users when spelled together. :)
I appreciate the effort, Desktop Java is a viable platform. I however, am not interested in using it due to the NPM aspect. Get ready, this won't be popular but it feels like if my toe were on fire an I dowsed it with gasoline to put out the fire.
> I however, am not interested in using it due to the NPM aspect
Some people (here and elsewhere) have expressed similar sentiments about NPM. What would be your preferred alternative? Self hosted? Github releases?
Originally I built it to be self hosted, but NPM was just so darned easy to work with and made the process smoother, so I focused on that. NPM is really just a CDN in this context.
If NPM works for you, I’d just stick with it. If I could choose, NPM wouldn’t even be on the list of options I’d consider. Honestly it’s a little weird using NPM, I mean you wouldn’t distribute Java application via CPAN either.
For the Mac: Brew, or just a download from a website.
For Linux: Download from a website or PPAs.
Again if NPM works, just stick with it, even if it weird.
I don't have a horse in this race, but being able to specify a generic target and then having a documented manifest format sounds nice to me?
Then you'd be able to do the ol' "specify base url" and as long as that host answers appropriately it should Just Work ( also doesn't stop you from then having npm configured as the default ); source freedom without blowing up configuration complexity
Publishing on the other hand I don't have easy recs for that don't eventually result in a lot of special-casing; That said, npm, git-compatible, s3-compatible, and ftp-compatible would cover most use cases, I think? Beyond those deployment types, custom deployment needs may well be better suited to pay you for a support contract anyway? )
> specify a generic target and then having a documented manifest format sounds nice to me?
It worked this way in an earlier iteration. I just wanted to make it simpler. I'll probably circle back and re-enable some of the more custom setups.
It does allow to you generate the apps and installers locally, but they are still "connected" to the cloud (NPM) for downloading the actual jar files and performing updates.
Would itch.io be a possibility? There are separate channels where updates are pushed, so you should be able to get a latest version per channel and go from there.
Speaking for myself, I could see this being useful to me if you targeted any kind of S3 target, along with something like Github Releases. Even just outputting the results to a filesystem location would be simple and appease a good chunk of the HN crowd I suspect.
Similar to GP I wouldn't be trusting NPM with this kind of thing. For the convenience factor of it though, you should definitely leave that in place.
No, I'd probably put them in the same category. This is why I suggested a filesystem output. Github is just popular and having something that could add it as a release to a repo would probably improve popularity of the project.
To be fair if your target segment is not privacy focussed HN crowd, think of an alternative option instead of npm release, dont try to replace it tho.
In real world very less people want to go thru the hurdle of seeing things up. HN crowd has been wrong in some huge projects. Take the feedback and implement if it makes sense to your target segment.
This actually serves an immediate need for us... we recently wrote a quite nice JavaFX desktop app to take care of some redundant data processing stuff and api pinging nonsense.
Glad to hear! Please share them when you post them. Looking for more samples for the homepage.
> Second coming of JNLP it looks like
Yeah. JNLP always still felt a bit second class to me. The move to native bundles was, all in all, a good step, but the process was always too cumbersome.
Some day... some day. I'd like a desktop toolkit that's designed around CDI / but more generally the Dependency Injection pattern. Imagine being able to break your application into chunks and @Observe events from user inputs.... ah, one can dream. But in case you get bored ;) I'll put that bug in you ear
Indeed! I never really understood how Sun screwed that part up so bad. It served a highly valuable need, but it seemed like they almost intentionally killed it by making the apps so awkward to deploy and manage from a security perspective it was non viable to use.
Why does it download a JVM separately instead of packaging the app with jpackage (which would result in a much smaller footprint)?
EDIT: I mean jlink - jpackage would be an alternative to creating installers, but jlink just packages the app with parts of the JVM it requires, which seems could make this tool better by avoiding the need so maintain JREs (which are deprecated) on the user's machine.
By managing the JVMs separately, you get major savings on updates, or if you have multiple apps deployed this way since they can share a JVM. When you update your app, it only needs to download your app - not the whole JVM. You can even change the JVM requirements in your version updates, and it will adjust to the new requirements when it updates, possibly even downloading a new JVM if it doesn't have one that meets the requirements yet.
The JVM updates very often now. This method of distribution doesn't work when pretty much all apps are almost guaranteed to used a different JVM (as others pointed out, downloading two apps from the samples already shows the problem).
With jlink , you don't need to download a whole JVM, it's usually a much smaller distribution. I have a LogFX application I distribute after passing it trhough jlink and it's around 30MB.
> This method of distribution doesn't work when pretty much all apps are almost guaranteed to used a different JVM
Not really. Currently it supports Java 8, 11, and 17. For each of those there is a JRE/JDK option, and a JavaFX option. Plus some of these are subsets. E.g. An app that doesn't need JavaFX can still use the JRE with JavaFX. And an app that doesn't need the full JDK can still use the JDK.
> as others pointed out, downloading two apps from the samples already shows the problem).
This was just an issue with the installer not needing JavaFX so downloading a non-javafx JRE first - but then the app needing JavaFX, so downloading one with JavaFX. This is a special case that will be resolved in an upcoming release by making the installer use a JRE that is compatible with the app to avoid the double download.
Anyways these are "fixed costs". Only incurred on first install. And, even then, maybe not if a compatible JVM is already present. All of your updates go through without the baggage of a JVM.
If you need more specific control over which JVM you're using than this (e.g. a specific build version or distribution), then jlink is a good tool for that. Life is about tradeoffs.
Cool! Ping me when you get around to it. I'm still trying to put together some more samples for the homepage if you're willing to let me post them there.
This does indeed solve a significant burden. Relying on npm seems a bit awkward. I might suggest using native packages, especially on mac; something like a DMG or .package.
1. npm solves a few problems here. By publishing to npm, the app is instantly available to be downloaded and installed by users.
2. Auto updating. The launcher will automatically check for updates on launch, and download them if any are found so that users are always working with your latest version.
I may add support for other CDNs - and originally I just had it so you self host. But npm removes a lot fo complexity. It only takes a minute to create an account, and then you can publish.
> I might suggest using native packages, especially on mac; something like a DMG or .package.
> Relying on npm seems a bit awkward.
1. npm solves a few problems here. By publishing to npm, the app is instantly available to be downloaded and installed by users.
2. Auto updating. The launcher will automatically check for updates on launch, and download them if any are found so that users are always working with your latest version.
I may add support for other CDNs - and originally I just had it so you self host. But npm removes a lot fo complexity. It only takes a minute to create an account, and then you can publish.
> I might suggest using native packages, especially on mac; something like a DMG or .package
The trouble with DMG and .pkg is that they need to be codesigned and notarized individually - which means you need a Mac and an Apple Developer account. Using jDeploy you don't need a Mac, and you don't need to worry about codesigning. This is because the installer is already signed and notarized. This probably the biggest pain point that I wanted to solve with jDeploy.
I had tried uploaded dmg to github (free hosting) and using github actions for the signing and notarization. Plus update4j for the automatic updates. All worked fine except for the notarization, never cracked this one.
Apologies for how much junk is in here[0], I finally figured out notarization and then lost the will to touch it. I'm planning on circling back to clean it up in a few weeks when that entire pile of stress is a bit more of a distant memory, but hopefully it's helpful? =)...
Yes the jDeploy installer is codesigned and notarized. The same installer is reused for every app. It figures out the specific app to be installed from a code in the installer name, so that, when run, the installer installs the correct app.
With a pkg I would need a different pkg for every app - which would need to be codesigned. Then we're back at the "need a mac to build mac app" issue. I wanted jDeploy fulfill WORA to whatever extent possible.
I got a tar file, which, when expanded, gave me an app. I launched the app (who's name I do not recall), which proceeded to download a JRE...somewhere, and gave me (I think) another app.
I launched that app, it, too, downloaded another JRE (so it said), and then launched the Ensemble app.
The Ensemble app worked fine, but none of the source code from the samples was visible. I don't know if that's a packaging issue or not.
All files related to it are kept in $HOME/.jdeploy
The observation that it downloaded 2 JREs (one for the installer and the other for the app) is a rough edge that will be fixed in an upcoming release. The reason is that the installer itself is an app that was bundled by jDeploy. It required a JRE, but didn't require JavaFX. When you, then launched the actual app, which was installed, it needed JavaFX, so couldn't use the JRE that was installed for the installer app, so it downloaded a JRE with JavaFX.
I will be optimizing this so that the "installer app" will try to use a JRE that meets both the installer requirements and app requirements so it only needs to download one JRE.
I think the feds might get to him first because the unfortunate reality is that the world is full of arseholes. One of those arseholes will surely use this system to distribute malware, and that malware will be signed with this guy's certificate. Which will lead the cops back to this guy.
I have a feeling that apple will have to wait their turn on this one. It's only a matter of time before the inevitable happens.
I've developed a lot of Java desktop apps and they use Apple Automator to start. This way I still get access to the disk without having to do the notarization.
If he has problems with Apple, it would be unfair compared to what is possible with Automator.
I'm getting an error about the SwingSet2 app being damaged when opening on macOS.
Looking at it with Signet, I get:
SwingSet2 Installer-1.0.5_255W/SwingSet2 Installer-1.0.5_255W.app error -67023 invalid resource directory (directory or signature have been modified)
The JavaFX Ensemble 8 Installer-1.0.8_255X app opens, but the experience is very un-Mac-like: the app is really a custom installer, and it places an app in `~/Applications/jDeploy Apps` instead of the expected /Applications. The resulting application then doesn't have the expected
The Unarchiver didn't like the JavaFX Ensemble 8 Installer-1.0.8_255X.tar.gz file, complaining about not being able to extract the Resources directory.
What version of Mac OS are you using? I've been testing on Mojave, Catalina, Big Sur, and Monterey. Can't seem to reproduce this (the "SwingSet2 damaged app)
Very interesting!
I would love to use, but my use case it's a bit weird :
- I need to not use public npm. A private npm repository or a simple old plain http server would be fine. As we only need to give an URL to our clients to download it.
- There is a way to control to what version auto updates ? I need to avoid that the client app auto updates to the wrong version, before the server and the database are updated.
In a previous iteration everything was designed to be self-hosted, but decided to focus on npm support because it made things much simpler. I'll be re-exposing the self-hosting, and private npm options as demand dictates.
> There is a way to control to what version auto updates?
Internally it supports some rich update rules. It is possible to generate apps that are pegged to a specific version (e.g. 1.0.7), or that will only update build updates (e.g. 1.0.), or minor updates (e.g. 1.). By default they don't update to pre-releases (e.g. 1.0.1-alpha.1), but this is configurable by the user.
I haven't documented this yet because I want to avoid confusion at the beginning as much as possible. There are dozens of variations that could be supported, but I'm trying to hit the 90% use case out of the box first...
> I need to avoid that the client app auto updates to the wrong version, before the server and the database are updated.
You could just bake that into your client (detect the server version). Alternatively, just wait until the server is updated before you publish the client update. This could be triggered in CI as well.
Nice, I’ve recently gone through setting up a build process with jpackage and it’s functional but things like code signing on the Mac and auto updates for free would be lovely to have. Couple of questions:
1) Can I run jlink somewhere in the build process?
2) Can I use a private npm repo like Verdaccio, or are there plans for other (non npm?) backends in the future?
> 1) Can I run jlink somewhere in the build process?
No need. Just specify your JVM requirements and the launcher will automatically use (or download if necessary) a compatible VM. This allows JVMs to be shared between apps, and your app updates are much smaller since they don't include the VM bundled directly.
> 2) Can I use a private npm repo like Verdaccio, or are there plans for other (non npm?) backends in the future?
Right now it's pegged to the public npm repo, but I'll be exploring other options soon, including private repos, self hosting, GitHub releases.
> Any plans for commercial features in the future?
I'll have to find out what kinds of features are of interest to commercial clients. I'd like to find some way to support continued development. Commercial features are certainly a possibility.
The launcher, which is written in Go and C, is precompiled, so it can be reused in all apps. This means that, unlike jpackage, which requires you to build the Windows installer on Windows, the Mac installer on Mac, etc..., you can build for any platform from any platform.
The idea is to fulfill the promise of WORA all the way to deployment. Everything is built and configured in a cross-platform way, and then is deployed as first-class native bundles on each platform.
Thanks Shannah for the tool. I have always thought oracle was so uncool (and shooting in its
own foot) not investing in better and easier deployment tool...
I really will definitely try it out for my free-visit builder installer. If it works well like some have said, boy you saved my day ♥. Love
I don't really understand what this is offering. Maybe someone could explain..
Can't you already do this with jpackage or graalvm to create native bundles?
At least with jpackage you already get an installer, versioning and upgradeability. I haven't tried graalvm'd native compiler but it should be possible as well.
> Can't you already do this with jpackage or graalvm to create native bundles?
With jpackage or graalvm you need a Windows machine to build your windows installer because it relies on 3rd party Windows tools for the installer. Likewise on Mac and Linux. Even worse, on Mac you need to Codesign and Notarize the app, which is painful every time.
> At least with jpackage you already get an installer, versioning and upgradeability.
With jDeploy, it will check for updates when the app launches, and will download them automatically, so your users are always on the latest version.
In the case of macOS I would prefer to have an standalone app rather than an installer... I personally try to avoid using the classical installation process in macOS if there is a '.app' alternative
Yes, there is an app alternative. You can generate an .app directly with jdeploy. However, then you need to code-sign and notarize the app if you want users who download it to not see a "This app is damaged" message. The installer solve the code-sign problem because the installer is code-signed, and it reuses the same installer app for apps. When the app itself is installed in this way, it doesn't face the same quarantine restrictions as it would if it were downloaded from the internet.
Hard to tell if this is sarcasm. However, I totally agree that learning about operating system packaging is a rewarding exercise. In developing jDeploy I had to learn a lot of details about OS packaging. Very interesting most of the time. Very frustrating at other times when all you want to do is build your app in a form that your users can easily install.
- Native installers for Mac, Windows, and Linux
- Build native bundles for all platforms from any platform (e.g. You don't need Mac to make a Mac app. You don't need Windows to make a Windows app, etc..)
- Auto updates. Your users automatically get the latest version on each launch
- Small installer bundle size (3mb compressed)
- No need to futz with Mac codesigning/notarization
- Instant download page so your users can download your app as soon as its published.
- Free, open source
Please take it for a spin, and let me know what you think.