Deploying Native Java Installers on GitHub
jDeploy 4.0 improves integration with the GitHub eco-system
When jDeploy was first announced, the single biggest complaint was that it used npm for its deployment. It didn’t matter that npm was “free”, or that it only takes a minute to create an account. Using npm just felt wrong to a lot of Java developers, as it was perceived as a tool for Javascript developers only.
I chose npm because it is free, cross-platform, ubiquitous, and easy to use. Publishing new releases was as simple as `npm publish`. (This was a stark contrast to the mounds of boilerplate and ceremony involved in publishing an artifact to Maven Central). After a year of npm-centric deployments, I can say that I’m satisfied with the result. There is currently no easier way to distribute a Java desktop app, in my humble opinion.
That said, I always planned to support other distribution channels, and I’m pleased to announce that jDeploy 4.0 will fully support hosting on GitHub. You no longer need to publish your app to npm - although you still can if you want to.
But it’s more than just hosting
jDeploy’s GitHub integration goes deeper than just “hosting” bundles on GitHub. There’s a new GitHub action that can be easily added to your existing workflows to generate native installers as artifacts in your GitHub release. Generating bundles that track the latest changes in your repo is as simple as adding the following snippet to your workflow:
- name: Build App Installer Bundles
uses: shannah/jdeploy@master
with:
github_token: ${{ github.token }}If the workflow runs on a commit to a branch, it will create a git tag, named after the branch, which includes all of your native artifacts.
As an example, you can check out this tag, which includes native installers corresponding to the “master” branch of the jdeploy-javafx-starter repo, which I’ll describe in more detail in a future post.
Branch-based Releases
When I first added GitHub support, I focused on “releases”, so that it replicated the current “npm” release process using GitHub releases. I.e. When you create a “Release” on GitHub, it automatically generates installers for that release, and adds them as artifacts on the GitHub release itself.
This was easy to add, and it worked pretty much the way you would expect it to. Auto-update worked the same as with npm releases. I looked at the result and said “this is good”. But I soon realized that I was leaving a lot of unrealized potential on the table.
For example. wouldn’t it be nice to have an app that is always in sync with the state of a branch on GitHub? Merge a change into “master”, and have this instantly available in the app.
And, while we’re at it, wouldn’t it be nice to be able to distribute different versions of your app, each one “bound” to a different branch on GitHub? E.g. A “dev” version, which is kept in sync with your repository’s “dev” branch, and a “stage” version that is kept in sync with your repository’s “stage” branch.
So I decided to add support for this, and the results are satisfying.
The GitHub action, if run on a “branch” commit, will publish native installers to a “tag” that has the same name as the “branch”. These installers are clearly marked with the branch name, to avoid confusion if you are distributing apps for multiple branches.
If you install one of these “branch” releases, they will automatically stay in sync with the latest changes in the branch.
When will this be available?
jDeploy is available right now in pre-release. You can add the GitHub action to your workflow using:
- name: Build App Installer Bundles
uses: shannah/jdeploy@master
with:
github_token: ${{ github.token }}Additionally, please take a look at the jdeploy-javafx-starter template repository which gives you a starting point with a bare-bones JavaFX project that has this workflow already baked in. This project is, perhaps, the easiest way to start building and distributing apps with JavaFX.
For More Information
I’ll be busy updating the jDeploy Developer Guide over the next few days to document all of the new features in 4.0. You can find more information there, or on the jDeploy website.
Feedback please
I developed jDeploy because I wanted to make Java a more compelling platform for desktop development. If you are a member of the Java community, please let me know your thoughts.
If you use jDeploy, what do you like and dislike about it? What can it do so solve your problems better.
If you don’t use it, why not? How can it be improved to support your use-cases?