Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Create a Windows installer for ImageJ2/Fiji #72
Right now, Fiji and ImageJ2 have the problem that if unpacked into the
However, there is a potential solution: distribute the Windows version of ImageJ using an installer such as NSIS or Inno Setup, and have the installer flag the entire ImageJ/Fiji directory as globally writable by all users.
Having a Windows installer will be good anyway because Windows users are most comfortable with them (just like OS X users are comfortable with DMG images which they mount and then copy the .app into
One wrinkle is that we still want to give a helpful error message if ImageJ/Fiji was manually unpacked into
referenced this issue
Apr 3, 2015
Please do not configure something that makes a program directory under a protected folder like C:\Program Files "globally writable by all users". That is a non-standard design and goes against all security recommendations. Users should only have modification rights within their own profile or (occasionally) in shared spaces (like some subdirectories of C:\ProgramData).
There is a better approach for installing ImageJ/Fiji as a system install that is available to run for all users. Install to C:\Program Files, keep those files protected from users (or malware) making any modifications, and create a service that will update ImageJ/Fiji as the SYSTEM account. It could be configured to auto-update, or be initiated from the menu as it is now.
Windows users sometimes complain about how weird/unintuitive it is that ImageJ cannot function properly out of Program Files like "normal" applications do—and I am inclined to agree. As long as users keep unpacking ImageJ and dumping it into
So, I think the best solution will be for ImageJ to be more flexible: by default, plugins should be installed into user space in standard locations—or failing that, at least something relatively platform-neutral like
Does that sound like an OK plan to you, @teknowledgist?
How would you suggest we run a Java-based Windows service? The Java Service Wrapper? Have you used it? My explicit goal for the future of ImageJ is no native code; I do not want to ship anything platform-specific or native, because the maintenance and testing burden is too high. I am very reticent to invest lots of effort into Windows-specific (or macOS-specific, or Linux-specific) layers of ImageJ, unless doing so creates a huge boost in usability somehow.
P.S. @teknowledgist since it looks like you are a Windows/Chocolatey enthusiast: any interest in helping with https://github.com/imagej/chocolatey-packages ? I would love to update/expand it to include ImageJ2, but have no bandwidth currently!
Absolutely! I didn't know this was an option.
I'm going to expose my ignorance here... My understanding (based on trying to find what version I would be downloading) is/was that ImageJ/Fiji was so much a collection of smaller pieces that there was no base program to "versionize". Thus there was no real means of a machine installation and occasional "managed" upgrades by admins (i.e. deployment) and allowing users to pick and upgrade their plugins on their schedule.
In my idealized world, system admins would be able to deploy an application and define the "required" plugins, the "default" plugins (that user's could disable), and then allow each user the ability to include their own library of plugins. Everything the admin pushed would update at the admin's discretion, and the user would update their pieces when they choose. In my experience, almost no software offers this, so I don't expect ImageJ to end up there either.
I can't suggest it one way or another because I know nothing about it, sorry. I appreciate your no native code goal. I don't mean to be the guy that asks for difficult/impossible things without knowing what I am doing, but I guess I have here.
Actually, I am here posting issues (and questions on the forum) because I was investigating creating a Chocolatey package.
I am not a developer by training (nor terribly knowledable of developer-y things), but I would be happy to continue toward both ImageJ2 and Fiji Chocolatey packages. However, I am trying to be pretty strict about making my Chocolatey packages be system (i.e. alluser) installs. (Ugh! The hoops I jumped through to make POV-Ray a system install!) My thinking for Fiji was to use Chocolatey to morph the current unzip-and-go, per-user (or insecure) design into a system install by locking it in Program Files and creating a scheduled task to run the updater. That would effectively be very close to what I think the installer requested in this issue should do.
I don't know if you want to have this discussion here or separately though. Feel free to contact me at my username at gmail.
referenced this issue
Mar 17, 2017
There is a base program: the one in this here repository. The artifact is
You are certainly not the first sysadmin to want that. I have discussed similar things with @carandraug and others in the past as well. I share your vision, particularly about mixing the system-available plugins with user-chosen ones. The thing I am less clear on supporting would be the ability for users to remove default plugins they don't like—I am not sure how we would implement that, nor even whether it is really necessary for people to be happy. If those defaults were automagically unpacked into the userspace area, then it would work. But already, with ImageJ2 you can add whatever you want to the classpath, and plugins are picked up automatically from those entries. So achieving this vision is not, in principle, very difficult. We mainly just need to improve the ImageJ Updater to better support it. This could be as simple as using
Not necessarily. You are posing requirements for your use case, and I am posing requirements as well. We discuss and find solutions which meet all requirements! Fun stuff.
I looked more closely at that Java service library I linked, but realized it is not open source, so we cannot use it. At the moment, I generally believe (but not very strongly) that a Windows service is probably not the way to go... happy to hear it argued otherwise though if you have a clear vision for how it would work, and how it might be achieved.
Awesome. I honestly know next to nothing about Chocolatey, but I'm happy to help where I can, especially if you have questions about how ImageJ2 is structured, or about Maven, etc. I can also comment on the internals of the Updater (to an extent—I didn't write it, but I generally know how it works).
I'll poke at some things.
I would really like to make an automatic package. That would allow for very easy updates to the package as ImageJ2/Fiji is/are updated. As noted in your initial steps into a Chocolatey package, there are a couple things I would need though:
I will also need to figure out how to get around the cmd-line update issue to do some logging.
Finally, is there a need for an ImageJ2 AND a Fiji package?
Agreed 100%. We want the process to be fully automated.
Just want to clarify that it is @AnthonyMastrean who deserves the credit for what has been done so far. I have not had time to move things forward any further yet.
You can look in the remote Maven repository:
Or you can ask Git:
There are no release notes, sorry. I still haven't developed a reasonable process to assist with generating/maintaining them.
Ultimately, the standalone app package will be built by Maven, via
Hmm, I dunno. Probably not. The vision is that any ImageJ installation can be turned into a Fiji one simply by enabling the Fiji update site. So a dedicated package is unnecessary. The main reason to have it would be social: some users, especially those in the EU, know the name "Fiji" better than "ImageJ" and might look for Fiji via a CLI search, and be disappointed when they don't find it.
I think it is friendlier to identify the currently downloading version on the front-end, "normal-user", Downloads page, but the Maven repository is suitable for automatic Chocolatey package update needs.
However, in testing, I'm a bit confused...
If I download what is offered on the download page, I would expect that to be the latest release. However, if I run
Also, even after the update, if I open Fiji/ImageJ and choose Help -> Update ImageJ..., I am offered to update that to 1.50k (from 1.5.0j). I thought the
I haven't had much chance to play with it, but at first glance it looks confusing.
If ImageJ2 has a userbase of its own and if Fiji is considered a plugin, depending on how it can be installed (i.e. via command line), I can see an argument for a Fiji package with ImageJ2 as a dependency. A user/admin asking Chocolatey to install Fiji would get ImageJ2 installed as a pre-req followed by Fiji (as a plugin). A user asking for ImageJ2 would just get that. They could be updated independently too (although it could get tricky if ImageJ2 is updated and won't work with the installed version of Fiji).
Thanks. Sorry if I'm being a PITA.
I am not sure what you mean by "friendlier". That Downloads page will not be updated every time a new release is cut; it simply links to an auto-generated archive of the newest available version. Therefore, you cannot deduce what the current version is by scraping the Downloads page.
It was. But not for the past 3 months. This job, which updates those archives, has been offline since we took down our Windows Jenkins node. And it cannot be brought back online until I find time to get the Windows part of the builds working with Appveyor, since we are not planning to redeploy our own Windows Jenkins node anymore.
I would say ImageJ and/or Fiji components are, on average, updated in batches every 2-8 weeks. But it varies depending on various factors.
The "Update ImageJ..." command updates ImageJ 1.x. The "Update..." command runs the ImageJ Updater which updates all components of ImageJ2, including ImageJ 1.x and its plugins. Very confusing, I know. Plans to change it, but no time—the usual story.
Fiji is an update site, meaning it is a suite of plugins for ImageJ. We also provide Fiji as a standalone distribution of ImageJ: it is just ImageJ plus all the plugins already installed.
My ultimate goal, probably still years away, is to get rid of the Fiji download and have only the base ImageJ download, which then asks the user what plugins they would like to install when it first starts. This will greatly simplify the Downloads, since all users will download and install the same thing initially.
No need to apologize. You are continuing the conversation, which is what needs to happen if we want to actually accomplish anything!
I know. I was suggesting that the average Joe might want to be able to see what the current release is, and it would be really helpful for them if the download page was updated each time there is a release. For example, the download table header could read "Download Fiji v2.0.0-rc-59 for your OS".
In testing, it looks like the
That would be great, but that is not my experience. I downloaded/unzipped, ran the
I assume you mean "update suite". How difficult is it currently to install (and uninstall) Fiji onto/into a basic install of ImageJ?
Argh. This Jenkins job is supposed to notice when the ImageJ 1.x release notes are updated. It then generates a commit in this clean ImageJ 1.x repository, which then triggers a deploy to the Maven repository via this job, which then uploads ImageJ 1.x to the ImageJ update site via this other job. In short: a lot of work happens under the hood when Wayne uploads a new release of IJ1 to his web site.
But it seems that the Jenkins URL polling is not working, since
I mean Update Site.
In practice, there is one snag: we are in the midst of transitioning to Java 8, and there is this third update site called "Java 8" which ships the latest versions of all core ImageJ2 and Fiji components. I want to separate them back out again, putting them back onto the respective ImageJ and Fiji update sites, but as soon as I do that, I will break all installations which are still using Java 6. I have a plan to fix that, but it requires some development time, which I have not yet had time to do. So for now, in practice, you must check the "Fiji" and "Java-8" boxes both, and make sure your installation is using Java 8, not Java 6, before doing so. Then your ImageJ will indeed transform into Fiji.
Ignorant question from a non-user: Why not offer a "clean" ImageJ2 that isn't bogged down with ImageJ1? What is the percentage of plugins/scripts that 1) rely on v1, 2) are used, 3) can't be rewritten/forked themselves, and 4) are on systems that also need v2 features?
Regarding the theoretical install of the Fiji update site: Is there any way to add/define a site when ImageJ isn't running so the install happens the next time ImageJ is started?
Alternately, you can also get a "clean" ImageJ2 by deleting/moving
That said, there are several reasons a "clean" ImageJ2 is not super useful to end users right now, such as:
The best data I have right now to address those questions is this spreadsheet.
The vague hand-waving answers are:
The vast majority.
Of course, most can be rewritten. And if you look at that spreadsheet above, you'll see that many have been. But it costs developer time. Our original goal was to rewrite everything and offer a new UI that looks like the old one, but is fully ImgLib2-driven under the hood. We got pretty far, but not far enough (yet) to satisfy the bulk of the existing use cases (e.g., Analyze Particles).
Well, "need" is relative. We have been encouraging people to switch to parameterized scripts, for example, and that is a v2 feature. Users can mix in usage of IJ1 APIs to those scripts, creating a result that needs both.
You can perform all of the updater-related actions using the command line updater.
So, I'm toying with starting from vanilla ImageJ2 and adding the Fiji and Java-8 update sites after and seeing a few sticking points off the bat...
I'm starting to wonder if an automatic Chocolatey package for Fiji is going to be like a Jenga game with me as a vision-impaired player.
I'll try to chime in with some answers on this one:
This is because currently all new updates for ImageJ and Fiji are shipped via the Java-8 update site, as explained by @ctrueden above. It will change once the transition to Java 8 is completed.
As far as I can see, a newly added site should be active by default (see this line), but maybe that only happens when you also specify host and upload directory?!
Ah! Sorry, I didn't really understand. Does that mean that not only will ImageJ not update without the Java-8 site, but adding the Java-8 site will (partially?) install the Fiji components too? IOW, currently, there is no way to have a fully updated vanilla ImageJ2?
OK, but does a site need to be added when it already exists in the list but just isn't enabled? I think of adding as maybe telling ImageJ about a private site. That is distinct from telling ImageJ to start using a site that it already knows about like the Java-8 and Fiji sites that can be just selected in the GUI (and are visible in the XML).
Well, you can build a vanilla ImageJ2 from the latest version using Maven. It will not match what is on the update sites. The goal is to unify these two mechanisms in the future, such that the Maven dependencies declared for a given version of ImageJ match what is uploaded to the core ImageJ update site, always.
IIRC, unfortunately, yes. There is no way via the CLI to simply say "turn on the Foo update site" when Foo is listed at https://imagej.net/List_of_update_sites. But you can simply give the URL explicitly. This allows for both of the use cases you stated, even if it is suboptimal.
A couple more questions about the updater... (I promise to stop soon.)
If it defines a local path for components, can it use variables to allow for a system-install with plugins going into user-space?
Edit: syntax error on my part hid an important part
First argument is the update site name, second is the update site URL. Here is an example of use.
You might also want to look at the bootstrap.js approach. While we will not continue to do things this way forever, it is currently how several automated processes work to build up ImageJ installations "from scratch" from the update sites, and it may be helpful for you here. You can see a couple of usage examples here and here.
The second argument is a path (typically a remote path, although I expect you could use
Hopefully that makes sense?
I really want to make the automated tooling here better, and built on Maven (since we are 90+% of the way there already!). In the meantime,
For now, I think we should focus on building a Chocolatey package for Fiji including the Java-8 site. In other words: a package that matches what you get currently when you download Fiji. However, we can make it work in a non-hardcoded way, such that when the Java-8 stuff gets untangled later, you can then start offering vanilla ImageJ2 super easily. Does that seem reasonable?
Doh! Part of my question disappeared. I edited the post to correct it. I was referring to one of the optional arguments.
I just found this other issue, so I'm going to move this discussion over there.