Login  Register

Re: Fiji Update Site: Dependencies

Posted by dscho on Jan 31, 2013; 6:14pm
URL: http://imagej.273.s1.nabble.com/Fiji-Update-Site-Dependencies-tp5001614p5001628.html

Hi Alexandre,

On Thu, 31 Jan 2013, Alexandre Dufour wrote:

> On 31 janv. 2013, at 16:47, Johannes Schindelin wrote:
>
> > Have a look here:
> >
> > http://fiji.sc/Update_Sites
> >
> > A slightly detailed technical overview can be found here:
> >
> > http://fiji.sc/Uploading_plugins#Internals
> >
> > If Icy is interested in using the Updater, I will be glad to make it work
> > for you.
>
> Thanks for the pointers. in fact I realize I already knew about the
> updater, since Icy has had the exact same system from day 1 (we just
> subjectively borrowed the term "repository" from the linux world rather
> that the Eclipse-centric "update site").

Heh... you make it sound like Icy is the only software that had an updater
from day one. In fact, I was a bit surprised when I learnt about Icy and
that it re-invented the whole shebang.

As to the term "update site": We had a quick (internal) survey when we had
to decide what to call the beast in October 2010, when I started to work
on third-party update sites.  The outcome was that users understood what
update sites are.

> I probably just got confused by the discussion about packing icons etc.
> in the right place/folder, wrongly assuming that the "update sites"
> actually led to full html pages online where the plugin icons would
> appear, like what we did with the Icy website (and I would have liked to
> see how it worked if that was the case).

Yes, the update sites supported by the Fiji/ImageJ updater are not
primarily web sites. The idea was that we did not want to dictate how
plugins are to be served. Indeed, since there is such a vast abundance of
ImageJ plugins with there own websites -- which existed well before Fiji's
first release in 2008 -- all such an enforced integration would have done
is to upset developers. That is why the update sites are basically static
files for consumption by the updater only.

> In our case, icons are submitted via the site's Content Management
> System (which feeds the "official" repository), separately from the jar,
> because it offered several advantages: 1) the web site automatically
> generates the plug-in web page online; 2) the various media and metadata
> published online alongside the jar can be displayed in-app either via
> the plugin browser, or via our new "spotlight"-like all-in-one search
> bar

Yes, having a tightly controlled environment is nice for such things. You
can even change the complete graphical layout from one day to another, and
it will trickle down to all the plugins' descriptions. Makes for nice
bling.

> (inspired from IJ2's search bar which we extended to do live plugin
> browsing/dowloading/running from the keyboard). I guess we could also
> adapt the system if you guys want to use the same distribution system,
> and even make this work for plain ImageJ.

Of course, I always welcome enhancements to the software I released as
Open Source. The Command Finder is an excellent example for vivid
collaboration: it was originally written by Mark Longair for Fiji,
accepted into ImageJ 1.x by Wayne, later enhanced more by Mark, Curtis and
me, then extended even more in ImageJ 2, a stripped-down version of which
was accepted into ImageJ 1.x again.

I will be glad to merge back every enhancement you want to contribute.

> Btw, seeing the screen captures on said pointers, does Fiji still need
> to be restarted when downloading/updating plugins? I thought I
> understood from a recent meeting this was solved (it took us hard effort
> to solve the problem and avoid restarting for every new plugin
> install/update).

Yes, Fiji still needs to be restarted in many circumstances. In general,
it is not possible to change the .jar files underneath the JVM (sometimes
it pretends that this is possible, but results in nasty crashes, or even
the inability to close ImageJ normally). Even if you load everything into
new class loaders: the images that have been opened before by classes
running in old class loaders (and mixing objects of the same class loaded
with different class loaders is not possible, for good reasons).

After trying a lot of strategies (on and off, our main focus is scientific
image analysis after all, and everything we do in Fiji is driven by
concrete, scientific goals), we settled for the following procedure: after
updating, the updater suggests to restart (which is the safe thing). But
it is quite possible to finalize the update by starting the updater again
-- it will warn the user about untoward things that might happen -- and
simply refresing the menus afterwards.

We found this to be an acceptable compromise between stability and
flexibility.

Ciao,
Johannes

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