Rebased on the current main branch. I threw the Flatpak Action into the "enabled" GitHub Action for now, as that makes testing easier (later those two files should obviously be merged and be enabled or disabled together, not separately)

Wow @ximion, thank you so much for working on this! I will go over this with @hinerm this week.

Sorry I haven't had time to review this yet. It's on my list for tomorrow April 13th. In the meantime, with imagej/imagej.github.io@8bf2e5b I have updated the Fiji Downloads page page to mention this work, since I agree that containerized solutions like Flatpak and Snap are a better fit for Fiji these days.

I'm just gonna say that I tested this by following the above instructions on Ubuntu 20.04 and it seems to work perfectly so far.

Sorry I haven't had time to review this yet. It's on my list for tomorrow April 13th. In the meantime, with imagej/imagej.github.io@8bf2e5b I have updated the Fiji Downloads page page to mention this work, since I agree that containerized solutions like Flatpak and Snap are a better fit for Fiji these days.

Awesome, thank you! I could also submit this to Flathub, however I am not sure whether this particular package would be welcomed, because we not only not properly build all code from scratch (Maven is downloading a lot of prebuilt components) but also don't have any separation between parts of Fiji and plugins, so the Flatpak has to copy all executable files to a mutable volume in the user's home directory because any one of them might be modified by new plugins or updated by Fiji's updater. That's pretty problematic. At the same time though, a thing like Steam is allowed, and the Steam Flatpak is handling this only slightly better, so Fiji might actually be fine if I polish the code a little ;-)

Sorry again for the slow review and merge on this. Had crunch time for the I2K conference, and now at another conference, so my normal PR reviewing schedule was thrown off. But I just wanted to say again that I'm enthusiastic. I will shoot to review this during my next PR day on Wednesday, May 18.

we not only not properly build all code from scratch (Maven is downloading a lot of prebuilt components)

And I can't resist the opportunity to rant here about packaging systems that want to rebuild Java code. The entire point of Java is "write ONCE" so downloading prebuilt binaries is exactly fine and correct, unlike with native code... 😞

And I can't resist the opportunity to rant here about packaging systems that want to rebuild Java code. The entire point of Java is "write ONCE" so downloading prebuilt binaries is exactly fine and correct, unlike with native code... disappointed

You often do want to verify though that the shipped code you have yields exactly the binaries you want, and that the code to generate said binaries is fully available in the first place (in case you want to modify it). The best way to ensure that is to build things from scratch.
You may also want to build it against newer Java versions, different JVM or do who-knows-what for a custom build.
Personally I'd like a toggle to enable or disable downloading of binary components, but in any case for this packaging effort here it doesn't really matter all that much - Flatpak just runs the result, no matter how it was built. :-)

I started looking at this today! But got distracted by the ImageJ Launcher patch. The good news is, that PR imagej/imagej-launcher#85 is now merged; the bad news is, the CI never got fully migrated to GitHub Actions after Travis stopped working, so I still need to complete that migration. But I'll punt on it for the moment in favor of testing and merging this PR here, since the patch is also applied manually when building the Flatpak package. I have some conflicts though for the rest of the day, so probably won't finish the review today. Will keep y'all updated.

Since this is linked on the Fiji download page, and since the patch needs rebasing and probably an update as well now, I created a pre-built bundle for people who navigate here and just want to give the easy Fiji installation a try.
For most users it should just require downloading the Flatpak file from https://github.com/ximion/fiji-builds/releases/tag/x-test and installing it with their graphical software center.

@ctrueden Would it be okay with you and others if I made an attempt to submit this to Flathub so Linux users can easily install the app? This will be a bit of a challenge, because in order to work well, Fiji/ImageJ will basically require maximum permissions (nearly no sandboxing, so plugins continue to work) and Fiji currently cannot be built from scratch - Maven just downloads a whole bunch of binary stuff at "build" time.

So, by attempting this, Fiji will become super easy to install after being available on Flathub, but I will need to submit a few patches to add some metadata and we may actually need versioned release tarballs that the Flatpak bundle will just use as "source" instead of building from scratch, as I currently see no way to build Fiji without network access (which is a requirement for Flathub).

I could do the work and talk to the Flathub admins, but I would need blessing from the Fiji authors to make this official, and would definitely like it if one of you would co-maintain the result (or at least have access to the resulting page on Flathub / Flathub GitHub to make changes if needed).

@ximion Yes, I definitely want to help make this happen! Thank you for the ping, and I apologize for my continual deferral of it as a priority for years. 😞 I am willing to maintain it going forward once it is in place. I just pushed an update modernizing the recipe to current standards—but I leaned on Claude quite a lot, so please let me know (or fix) if anything looks suboptimal.

Edit: I also rebased over the latest main branch to resolve the conflicts.

we may actually need versioned release tarballs that the Flatpak bundle will just use as "source" instead of building from scratch

Can we use the timestamps from https://downloads.imagej.net/fiji/archive/latest/ ?

What else needs to happen to move this forward?

We would need to decide whether we want to distribute this via Flathub or roll our own.

If we go via Flathub, it would reach the widest user audience, be simple to install, and have automatic updates (although we copy Fiji to the user's home directory anyway and use the local updater, since this is the only way that updates work...).

The problems we will run into with Flathub is that some arguing is needed to get it in, because we will have to disable basically all sandboxing features to make this work, which always raises concern. In addition to that, no network-enabled builds are permitted, so we would likely need to fetch a tarball from somewhere.

Flatpak builds on Flathub need to be reproducible, so we can't just fetch a "latest" tarball, but we need one with a defined version number. So, Fiji would need to provide versioned tarballs.
We will also have to make Fiji ship an AppStream MetaInfo file (trivial to do, but to keep it up-to-date with the latest Fiji version, some work may be needed).

Fiji still requires Java 8, right? We can not make it use any newer JDK? We'll also have to justify that, most likely.

Plus, once the application is accepted, verification for the app would need to be set up via the Fiji website, have a look at https://docs.flathub.org/docs/for-app-authors/verification for details.

All of these items I can help with because I have now done them many times and know the Flathub devs (and have annoyed them with sandbox-less scientific apps many times by now).

The alternative is just shipping a Flatpak file or setting up our own repo, which comes with its own drawbacks, but tbh, I'd make an attempt at Flathub before going that route.

Can we use the timestamps from https://downloads.imagej.net/fiji/archive/latest/ ?

That could work, but only if we have the automation also generate a MetaInfo file with the right version number. We need to attach a version number to Fiji, and ideally make that part of the tarball name (but not required, as long as it's in the path and the MetaInfo file has it). So, e.g. we could version the release from 20260302 as 26.0302, that would be sufficient (we only will never be able to decrease that version number once it's set, it needs to be increasing).

Oh, and I almost forgot: We also need a good screenshot of Fiji hosted somewhere on the web, although that most certainly won't be an issue ^^

For reference, I just recently submitted a tiny app to Flathub, this is how the resulting page looks like: https://flathub.org/en/apps/io.github.bothlab.omerewriter

And this is how the review process for Flathub looked like: flathub/flathub#7960

I can take care of most of the work (since the heavy lifting is done), but you would need to version Fiji first, and we would have to add a MetaInfo file with a proper screenshot and description first. I can have a look if that can be automated somehow, then making the Flatpak becomes easy.