Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make it possible to complete disable the ImageJ updater #7

Closed
ctrueden opened this Issue Apr 30, 2014 · 7 comments

Comments

Projects
None yet
3 participants
@ctrueden
Copy link
Member

commented Apr 30, 2014

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

This comment has been minimized.

Copy link
Member

commented Apr 30, 2014

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.

@dscho dscho closed this Apr 30, 2014

@ctrueden

This comment has been minimized.

Copy link
Member Author

commented Apr 30, 2014

My main concern was:

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

And I did so like so:

protected void onEvent(@SuppressWarnings("unused") final UIShownEvent evt) {

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" 😁

@ctrueden

This comment has been minimized.

Copy link
Member Author

commented Apr 27, 2015

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

This comment has been minimized.

Copy link

commented Oct 20, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Oct 20, 2016

@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

This comment has been minimized.

Copy link

commented Oct 21, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Oct 21, 2016

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.