Make it possible to completely disable the ImageJ updater

[ctrueden]

Sometimes people want to deploy a version of Fiji that never checks for updates, and/or does not even have updater functionality at all, preferring to carefully control the updates themselves using an alternative mechanism (e.g., Git).

We should make sure the architecture of ImageJ2 allows for this.

For example, right now, Fiji tries to invoke the remote ImageJ updater if ij-updater*.jar is missing from its installation, and ImageJ2 has a hardcoded invocation of the UpToDate command directly in AbstractUserInterface, which is definitely the wrong approach. Better would be for commands to be able to annotate themselves as auto-run, and/or have a flexible auto-run mechanism that by default ships with the UpToDate check included. That way, users can just remove the UpToDate check from the auto-run configuration to disable the updater.

Migrated-From: http://trac.imagej.net/ticket/2035

[dscho]

It is very easy for people who want to bundle a Fiji that does not check the updater: remove Fiji_Updater.jar from the directory, and bundle that.

Seriously, we should not try to focus on tickets that make Fiji/ImageJ less useful. We should focus on tickets that make it more useful.

If there is strong enough desire to implement something like a permanent update disabler: this is Open Source. Nothing is stopping the people who want to do this from doing this.

[ctrueden]

My main concern was:

We should make sure the architecture of ImageJ2 allows for this.

And I did so like so: https://github.com/imagej/imagej-updater/blob/c65cd8e9820c929a6e9f8a904fa4604a9a928502/src/main/java/net/imagej/updater/DefaultUpdateService.java#L67

In other words: the Updater is no longer hardcoded into the UI. So it no longer breaks things to remove it from the distribution.

So I would argue that this issue is actually "resolved" as opposed to "wontfix" :grin:

[ctrueden]

For those stumbling across this issue these days: note that Fiji_Updater is now obsolete, and removing it will not disable the updater. This is because Fiji_Updater is simply a backwards compatibility stub that adds the "Update Fiji" command to the help menu. The actual updater now lives in imagej-ui-swing. So it no longer possible to disable the updater by deleting a particular JAR file.

However, here is one possible way of disabling it. Create the following class, make a JAR and put that JAR into the ImageJ.app/jars folder:

package foo.bar;

import net.imagej.updater.DefaultUpdateService;
import net.imagej.updater.UpdateService;

import org.scijava.Priority;
import org.scijava.plugin.Plugin;
import org.scijava.service.Service;
import org.scijava.ui.event.UIShownEvent;

/** {@link UpdateService} which disables update checking at startup. */
@Plugin(type = Service.class, priority = Priority.HIGH_PRIORITY)
public class NoUpdaterUpdateService extends DefaultUpdateService {

    // -- Event handlers --

    /** Override the initial update check, to never do anything. */
    @Override
    protected void onEvent(final UIShownEvent evt) {
        // NB: Do nothing.
    }

}

[eCrofey]

Hi I need to dissable the update function,but my coding skills 're very small. can you please update the files so I can intergrate it into the install package. it would help me a lot.

[ctrueden]

@eCrofey You can simply delete jars/imagej-updater-*.jar, also optionally jars/imagej-plugins-uploader-*.jar.

it no longer possible to disable the updater by deleting a particular JAR file.

I was wrong above; I tested it, and it does indeed disable the updater to delete jars/imagej-updater-*.jar. The imagej-ui-swing component does ship the graphical ImageJ Updater plugin, which simply fails to initialize (and startup continues) when its required image-updater dependency is missing. We could perhaps work to improve this further by splitting out the ImageJ Updater Swing UI, but it should not be a showstopper.

Also @eCrofey: I would love to hear about your use case for packaging ImageJ as an MSI. We will probably do this in the future as well; see imagej/imagej#118. In general, I would prefer packagers contact us upstream to help with unified packaging efforts, rather than "secretly" packaging ImageJ and upstream not knowing about it.

[eCrofey]

Great thanx a Lot ! Package works well.The problem we have is that the updater need write rights on installation folder and this is contrary to our security and SLA guidelines.The second issue we have was that in the console window we have an red information why the updater can't work propery.This is werry nice but customer see only the red text and think there is an error in the application so we need to dissable it.however thanks again for your help and have a nice day.

[ctrueden]

@eCrofey There are plans to improve this situation, as part of completing the migration to Java 8 + a new application launcher. Unfortunately, it is currently 10th on my list of priorities so it will be quite some time before I can work on it.

Note that you can install plugins into the .plugins folder of the user's home directory, and ImageJ should pick them up there too, although I have not tested this in a while. Of the top of my head, I do not know whether it is possible to use that folder for plugin updates rather than the application folder, but I doubt it.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/fiji-updater-and-csbdeep-dependency/52302/2

[imagejan]

Reopening this, as it seems there are some community use cases (packaging, centralized management of institutional installations, ...) where we need a better (and simple) way to disable the updater.

[ctrueden]

As of imagej/imagej-updater@b69709ca8a0af98f8331b8ce9ba19731a4f90b73, part of imagej-updater-0.10.4 and later, you can pass -Dimagej.updater.disableAutocheck=true when launching, and the automatic update check will be skipped.

What else does the community need here? Do we need an environment variable? Maybe something like IMAGEJ_UPDATER_DISABLE=1 which makes the Updater always refuse to run? Do we also need a system property to similarly disable the Updater completely rather than only the auto-update check at the beginning?

@lguerard @eCrofey Your input here would be helpful. What do you want to have happen when the user tries to run Help > Update...? Nothing? An error?

[lguerard]

Thanks for the info, didn't know about the launch command !

What else does the community need here? Do we need an environment variable? Maybe something like IMAGEJ_UPDATER_DISABLE=1 which makes the Updater always refuse to run? Do we also need a system property to similarly disable the Updater completely rather than only the auto-update check at the beginning?

The main issue we have right now, is that removing the updater JAR breaks everything deep learning in Fiji. I guess disabling the updater would do the same no ? If it doesn't, then this would be perfect. But If it does, then I guess just disabling the auto-update check at the beginning should be enough as (hopefully) users won't be tempted to update unless they really need/want it. What do you think @ehrenfeu ?

[ctrueden]

I guess disabling the updater would do the same no ?

I don't think so, because the UpdateService and related classes would still be there and available, they just wouldn't do anything. So I think the deep learning stuff will still work.

What I need to know is: how are you deploying this to users? Do you have control over:

• the program launch (i.e. you could add -Dimagej.updater.disableAutocheck=true)
• the environment (i.e. you could set IMAGEJ_UPDATER_DISABLE=1)
• the packaging (e.g. you could tweak something in the .zip users download such as adding an imagej2.cfg file with an [updater] section with enabled = false)
• something else?

[lguerard]

What I need to know is: how are you deploying this to users?

The way we do it is to download a brand new Fiji, add updates sites with a python script and then run the updater. Once this is done we move the updater JAR to a different a disabled/jars/ folder. Then we copy the whole Fiji folder to all our machines and put the shortcut on the desktop. We also add an extra imageJ.cfg file to set up the RAM usage based on specific machines we have. The deployment to all the machines as well as the shortcut creation is done through a PowerShell script.

So to answer your questions, we control more or less everything inside the Fiji folder and shortcut. I could have a look at adding the launch argument to the shortcut as well and see if that works.

EDIT : Just tested adding the argument to the shortcut and it works super nicely, thanks for this ! As long as the updater is needed to run deep learning plugins, this is a perfectly working solution ! :)

[DuncanClarke]

Sorry to drag up this old query; just wanted to know if there is an official deployment method which doesn't allow users to run updates. I mean we can add a link with the -Dimagej.updater.disableAutocheck=true but users being users, I suspect they would find a way to launch it without this.

What we are looking for is a way to install this system-wide (C:\Program Files) such that users won't get errors from attempting to run updates. If an update is needed, we will do it centrally. Any "personal" installs will be blocked from running.

[mkitti]

I'm going to guess this would be more easily addressed with https://github.com/scijava/jaunch