100% agree. The "distribution" step has always taken way more time than I expected. And, I almost always had to compromise on certain platforms just because it couldn't get the square peg in to the round hole.
The goal of jDeploy is to sand off as many of these rough edges as possible to make cross-platform distribution as easy as cross-platform development.
The FileDialog is the only AWT widget I still use regularly. It gives you the native file chooser. Unfortunately it isn't terribly flexible when it comes to, for example, only selecting directories. In those cases, I have been known to use JNI to use the truly native dialog.
I started from the other side of that fence, and I remember feeling jealous of how smooth the GUI editor was in Visual Studio. Even in 2022, I still don't think I've seen any Java GUI builders that are as easy to use as Visual Studio circa 2001/2.
SceneBuilder is nice though.
I can't disagree with anything you say here, except the thing about "the article seems quite off". lol.
This piece covers the state of the technology at that time. In the early 2000's Java was slow. I wasn't familiar with IntelliJ at that time, so can't comment on their performance then. I wouldn't expect it to be dramatically better than other Java apps on the market at that time.
Moore's law has steadily changed the landscape. So have improvements in JIT technology.
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.
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.
> 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.
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.
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)
The goal of jDeploy is to sand off as many of these rough edges as possible to make cross-platform distribution as easy as cross-platform development.