Blocking Fiji's Updater

[Olivier Burri]

Dear ImageJ/Fiji list,

We're using Git to keep a good working copy of Fiji with all our custom plugins and modifications. This way we can deploy a copy very easily on all our computers. An update site was not good enough for us, as we're using several plugins that do not yet have their update sites. Also sometimes (And I do say only sometimes) an update will break some older plugin until we fix it, and Git makes it super fast to revert to the previous state.

The idea here is that we do not want the users of our computers to do the updates of Fiji. As the "Image Processing Analysts" (Which seems to be our new name), we want to get the update, make sure we have the latest copy running properly and only then commit it to our Git server.
Whenever a user opens Fiji through a shortcut, the latest branch is pulled from the server and we are now sure that they are running the same version as us.

However using Git this way makes the Fiji Updater unhappy and it sees many locally modified files and prompts for an update at every run

So my question is this: Is there a way to have the updater not automatically check for updates?

Best regards,

Oli

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Oli,

> Is there a way to have the updater not automatically check for
> updates?

On a per-user level, yes. However, we have not yet exposed the Updater's
auto-checker setting in the user interface. But here is a Beanshell
one-liner that will disable it forever for the current user:

imagej.util.Prefs.put(imagej.updater.core.UpToDate.class, "latestNag",
Long.MAX_VALUE);

Note however that since the Updater is an ImageJ2 component and ImageJ2 is
still in beta, this could be subject to change...

Unfortunately, this will not disable the Updater globally for all users to
whom you deploy the software. And you cannot just delete ij-updater-*.jar
from your installation; Fiji tries to "recover" from that situation --
historically, users sometimes ended up with a bogus updater configuration
by accident and needed Fiji to be aggressive to repair itself in that case.

I'll discuss with Johannes the best way forward; we may need to make some
improvements to the Updater to make it possible to fully disable it from a
deployment standpoint.

I filed three new tickets related to this thread, and a related discussion
on IRC earlier today [1]:

Make it possible to complete disable the ImageJ updater
http://trac.imagej.net/ticket/2035

Expose the Updater's UpToDate check setting in Edit > Options
http://trac.imagej.net/ticket/2036

Use ImageJ.cfg to store all settings
http://trac.imagej.net/ticket/2037

None of that solves your problem today, but hopefully soon.

Regards,
Curtis

[1] For those curious, here is the transcript:

qwebirc97302
hi there
can someone tell where is stored the "disable Fiji updater" setting ?
I distribute the "long life" version of Fiji, and would like to make sure
it's disabled

ctrueden
qwebirc97302: Let me check.

qwebirc97302
I'm digging into imagej/updater/core/UpToDate.java
and it looks like it's a pref set by IJ
but, the thing is that there's no file saved in the directory (I checked I
have write access) after I clicked on "never"
I just had a "ImageJ.cfg" file created when I changed the max memory

ctrueden
qwebirc97302: It uses the Java Preferences API, like the rest of ImageJ2.
It is stored under the package imagej.updater.core, with key latestNag.
Where Java Preferences are stored is OS-specific.
We may change this before ImageJ2 comes out of beta, to be easier to edit
by hand, but right now, that's how it's done.
I can add a menu command Edit > Options > Updater or some such, if that
would help you.
qwebirc97302: Is this question related to the "Blocking Fiji's Updater"
thread on ImageJ mailing list? Or coincidental?
I suppose we could ditch the Java Preferences API in favor of dumping
everything into ImageJ.cfg. :-)
That would be rather more convenient.

qwebirc97302 left the room (quit: Ping timeout: 272 seconds).


On Fri, Dec 13, 2013 at 10:53 AM, Burri Olivier <[hidden email]>wrote:

> Dear ImageJ/Fiji list,
>
> We're using Git to keep a good working copy of Fiji with all our custom
> plugins and modifications. This way we can deploy a copy very easily on all
> our computers. An update site was not good enough for us, as we're using
> several plugins that do not yet have their update sites. Also sometimes
> (And I do say only sometimes) an update will break some older plugin until
> we fix it, and Git makes it super fast to revert to the previous state.
>
> The idea here is that we do not want the users of our computers to do the
> updates of Fiji. As the "Image Processing Analysts" (Which seems to be our
> new name), we want to get the update, make sure we have the latest copy
> running properly and only then commit it to our Git server.
> Whenever a user opens Fiji through a shortcut, the latest branch is pulled
> from the server and we are now sure that they are running the same version
> as us.
>
> However using Git this way makes the Fiji Updater unhappy and it sees many
> locally modified files and prompts for an update at every run
>
> So my question is this: Is there a way to have the updater not
> automatically check for updates?
>
> Best regards,
>
> Oli
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Olivier Burri]

Dear Curtis,

Thanks for the info. Just curious. This one-liner:
> imagej.util.Prefs.put(imagej.updater.core.UpToDate.class, "latestNag", Long.MAX_VALUE);

I could add it to a startup macro to my setup and push this to our Git server, that way this gets configured for each user?

Would that work?

Thank you and all the best

Oli

Olivier Burri
Engineer - Image Processing
& Software Development
EPFL - SV - PTECH - PTBIOP

-----Original Message-----
From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Curtis Rueden
Sent: vendredi 13 décembre 2013 19:07
To: [hidden email]
Subject: Re: Blocking Fiji's Updater

Hi Oli,

> Is there a way to have the updater not automatically check for
> updates?

On a per-user level, yes. However, we have not yet exposed the Updater's auto-checker setting in the user interface. But here is a Beanshell one-liner that will disable it forever for the current user:

imagej.util.Prefs.put(imagej.updater.core.UpToDate.class, "latestNag", Long.MAX_VALUE);

Note however that since the Updater is an ImageJ2 component and ImageJ2 is still in beta, this could be subject to change...

Unfortunately, this will not disable the Updater globally for all users to whom you deploy the software. And you cannot just delete ij-updater-*.jar from your installation; Fiji tries to "recover" from that situation -- historically, users sometimes ended up with a bogus updater configuration by accident and needed Fiji to be aggressive to repair itself in that case.

I'll discuss with Johannes the best way forward; we may need to make some improvements to the Updater to make it possible to fully disable it from a deployment standpoint.

I filed three new tickets related to this thread, and a related discussion on IRC earlier today [1]:

Make it possible to complete disable the ImageJ updater
http://trac.imagej.net/ticket/2035

Expose the Updater's UpToDate check setting in Edit > Options
http://trac.imagej.net/ticket/2036

Use ImageJ.cfg to store all settings
http://trac.imagej.net/ticket/2037

None of that solves your problem today, but hopefully soon.

Regards,
Curtis

[1] For those curious, here is the transcript:

qwebirc97302
hi there
can someone tell where is stored the "disable Fiji updater" setting ?
I distribute the "long life" version of Fiji, and would like to make sure it's disabled

ctrueden
qwebirc97302: Let me check.

qwebirc97302
I'm digging into imagej/updater/core/UpToDate.java and it looks like it's a pref set by IJ but, the thing is that there's no file saved in the directory (I checked I have write access) after I clicked on "never"
I just had a "ImageJ.cfg" file created when I changed the max memory

ctrueden
qwebirc97302: It uses the Java Preferences API, like the rest of ImageJ2.
It is stored under the package imagej.updater.core, with key latestNag.
Where Java Preferences are stored is OS-specific.
We may change this before ImageJ2 comes out of beta, to be easier to edit by hand, but right now, that's how it's done.
I can add a menu command Edit > Options > Updater or some such, if that would help you.
qwebirc97302: Is this question related to the "Blocking Fiji's Updater"
thread on ImageJ mailing list? Or coincidental?
I suppose we could ditch the Java Preferences API in favor of dumping everything into ImageJ.cfg. :-) That would be rather more convenient.

qwebirc97302 left the room (quit: Ping timeout: 272 seconds).


On Fri, Dec 13, 2013 at 10:53 AM, Burri Olivier <[hidden email]>wrote:

> Dear ImageJ/Fiji list,
>
> We're using Git to keep a good working copy of Fiji with all our
> custom plugins and modifications. This way we can deploy a copy very
> easily on all our computers. An update site was not good enough for
> us, as we're using several plugins that do not yet have their update
> sites. Also sometimes (And I do say only sometimes) an update will
> break some older plugin until we fix it, and Git makes it super fast to revert to the previous state.
>
> The idea here is that we do not want the users of our computers to do
> the updates of Fiji. As the "Image Processing Analysts" (Which seems
> to be our new name), we want to get the update, make sure we have the
> latest copy running properly and only then commit it to our Git server.
> Whenever a user opens Fiji through a shortcut, the latest branch is
> pulled from the server and we are now sure that they are running the
> same version as us.
>
> However using Git this way makes the Fiji Updater unhappy and it sees
> many locally modified files and prompts for an update at every run
>
> So my question is this: Is there a way to have the updater not
> automatically check for updates?
>
> Best regards,
>
> Oli
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Oli,

> I could add it to a startup macro to my setup and push this to our Git
> server, that way this gets configured for each user?

Yes, I think that would work. Off the top of my head though, I am not sure
whether startup macros execute before the UpToDate check launches. So there
might be a race condition the first time Fiji is launched. We definitely
need to resolve some of the tickets I filed to make the Updater more
configurable. In the meantime, your idea is worth a shot.

Regards,
Curtis


On Wed, Dec 18, 2013 at 9:06 AM, Burri Olivier <[hidden email]>wrote:

> Dear Curtis,
>
> Thanks for the info. Just curious. This one-liner:
> > imagej.util.Prefs.put(imagej.updater.core.UpToDate.class, "latestNag",
> Long.MAX_VALUE);
>
> I could add it to a startup macro to my setup and push this to our Git
> server, that way this gets configured for each user?
>
> Would that work?
>
> Thank you and all the best
>
> Oli
>
> Olivier Burri
> Engineer - Image Processing
> & Software Development
> EPFL - SV - PTECH - PTBIOP
>
> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of
> Curtis Rueden
> Sent: vendredi 13 décembre 2013 19:07
> To: [hidden email]
> Subject: Re: Blocking Fiji's Updater
>
> Hi Oli,
>
> > Is there a way to have the updater not automatically check for
> > updates?
>
> On a per-user level, yes. However, we have not yet exposed the Updater's
> auto-checker setting in the user interface. But here is a Beanshell
> one-liner that will disable it forever for the current user:
>
> imagej.util.Prefs.put(imagej.updater.core.UpToDate.class, "latestNag",
> Long.MAX_VALUE);
>
> Note however that since the Updater is an ImageJ2 component and ImageJ2 is
> still in beta, this could be subject to change...
>
> Unfortunately, this will not disable the Updater globally for all users to
> whom you deploy the software. And you cannot just delete ij-updater-*.jar
> from your installation; Fiji tries to "recover" from that situation --
> historically, users sometimes ended up with a bogus updater configuration
> by accident and needed Fiji to be aggressive to repair itself in that case.
>
> I'll discuss with Johannes the best way forward; we may need to make some
> improvements to the Updater to make it possible to fully disable it from a
> deployment standpoint.
>
> I filed three new tickets related to this thread, and a related discussion
> on IRC earlier today [1]:
>
> Make it possible to complete disable the ImageJ updater
> http://trac.imagej.net/ticket/2035
>
> Expose the Updater's UpToDate check setting in Edit > Options
> http://trac.imagej.net/ticket/2036
>
> Use ImageJ.cfg to store all settings
> http://trac.imagej.net/ticket/2037
>
> None of that solves your problem today, but hopefully soon.
>
> Regards,
> Curtis
>
> [1] For those curious, here is the transcript:
>
> qwebirc97302
> hi there
> can someone tell where is stored the "disable Fiji updater" setting ?
> I distribute the "long life" version of Fiji, and would like to make sure
> it's disabled
>
> ctrueden
> qwebirc97302: Let me check.
>
> qwebirc97302
> I'm digging into imagej/updater/core/UpToDate.java and it looks like it's
> a pref set by IJ but, the thing is that there's no file saved in the
> directory (I checked I have write access) after I clicked on "never"
> I just had a "ImageJ.cfg" file created when I changed the max memory
>
> ctrueden
> qwebirc97302: It uses the Java Preferences API, like the rest of ImageJ2.
> It is stored under the package imagej.updater.core, with key latestNag.
> Where Java Preferences are stored is OS-specific.
> We may change this before ImageJ2 comes out of beta, to be easier to edit
> by hand, but right now, that's how it's done.
> I can add a menu command Edit > Options > Updater or some such, if that
> would help you.
> qwebirc97302: Is this question related to the "Blocking Fiji's Updater"
> thread on ImageJ mailing list? Or coincidental?
> I suppose we could ditch the Java Preferences API in favor of dumping
> everything into ImageJ.cfg. :-) That would be rather more convenient.
>
> qwebirc97302 left the room (quit: Ping timeout: 272 seconds).
>
>
> On Fri, Dec 13, 2013 at 10:53 AM, Burri Olivier <[hidden email]
> >wrote:
>
> > Dear ImageJ/Fiji list,
> >
> > We're using Git to keep a good working copy of Fiji with all our
> > custom plugins and modifications. This way we can deploy a copy very
> > easily on all our computers. An update site was not good enough for
> > us, as we're using several plugins that do not yet have their update
> > sites. Also sometimes (And I do say only sometimes) an update will
> > break some older plugin until we fix it, and Git makes it super fast to
> revert to the previous state.
> >
> > The idea here is that we do not want the users of our computers to do
> > the updates of Fiji. As the "Image Processing Analysts" (Which seems
> > to be our new name), we want to get the update, make sure we have the
> > latest copy running properly and only then commit it to our Git server.
> > Whenever a user opens Fiji through a shortcut, the latest branch is
> > pulled from the server and we are now sure that they are running the
> > same version as us.
> >
> > However using Git this way makes the Fiji Updater unhappy and it sees
> > many locally modified files and prompts for an update at every run
> >
> > So my question is this: Is there a way to have the updater not
> > automatically check for updates?
> >
> > Best regards,
> >
> > Oli
> >
> > --
> > ImageJ mailing list: http://imagej.nih.gov/ij/list.html
> >
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Olivier,

On Wed, 18 Dec 2013, Burri Olivier wrote:

> Thanks for the info. Just curious. This one-liner:
> > imagej.util.Prefs.put(imagej.updater.core.UpToDate.class, "latestNag", Long.MAX_VALUE);
>
> I could add it to a startup macro to my setup and push this to our Git server, that way this gets configured for each user?
>
> Would that work?

Since this would also work around the problems with the massive stitcher
containing obsolete .class files, that would probably be a good idea.

However, this would not be Fiji anymore: the updater was and is the most
useful Fiji feature.

And since it would not be Fiji without the updater anymore, and since
users could not simply install another Fiji that would get auto-updated as
it should be, I foresee exactly the same type of trouble as with the
massive stitcher, and I would like not having to deal with the diagnosis
of such problems myself again.

Therefore, I suggest to make a modified Fiji *and label it as such* so that
users do not think that this is Fiji. This modified Fiji should have a
modified updater that does not perform the up-to-date check at all.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html