http://imagej.273.s1.nabble.com/Blocking-Fiji-s-Updater-tp5005907p5005939.html
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
configurable. In the meantime, your idea is worth a shot.
> 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>