Login  Register

Fiji Update Site: Dependencies

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options Options
Embed post
Permalink
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Fiji Update Site: Dependencies

Olivier Burri
Dear List,

A While back we heard of the Fiji Update Site concept from Johannes which would be great for us to distribute the few macros and plugins our users have come to enjoy using on our platform.

After a few unsuccessful attempts, we've got it up and running no problem.

I was just curious on whether the updater could add other files to the update site. For instance, we have an ActionBar that contains icons in .png format. We can upload the actionBar to the update site but the icons, if added as a dependency, are considered as an "obsolete/local-only dependency".

Would there be a way to overcome this?

Thanks!

Oli

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

Stephan Saalfeld
Wild guess, have you tried uploading a jar file into the plugins or jar
directory that contains only the png icons?  I suspect this to work as
for Java plugins, I bundle the required `external' files in the jar
file.

Best,
Stephan



On Thu, 2013-01-31 at 09:17 +0000, Burri Olivier wrote:

> Dear List,
>
> A While back we heard of the Fiji Update Site concept from Johannes which would be great for us to distribute the few macros and plugins our users have come to enjoy using on our platform.
>
> After a few unsuccessful attempts, we've got it up and running no problem.
>
> I was just curious on whether the updater could add other files to the update site. For instance, we have an ActionBar that contains icons in .png format. We can upload the actionBar to the update site but the icons, if added as a dependency, are considered as an "obsolete/local-only dependency".
>
> Would there be a way to overcome this?
>
> Thanks!
>
> Oli
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

Olivier Burri
Hello,
> I suspect this to work as for Java plugins, I bundle the required `external' files in the jar file.

This indeed works for plugins, but as we're talking of an Action Bar, it's just some .ijm macro code, which the Fiji updater takes into account.
The icons, to be accessible by the Action Bar, need to be in a folder within the "plugins/actionBar/icons" directory, which is why I wanted trying to upload them separately.

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 Stephan Saalfeld
Sent: jeudi 31 janvier 2013 12:08
To: [hidden email]
Subject: Re: Fiji Update Site: Dependencies

Wild guess, have you tried uploading a jar file into the plugins or jar directory that contains only the png icons?  I suspect this to work as for Java plugins, I bundle the required `external' files in the jar file.

Best,
Stephan



On Thu, 2013-01-31 at 09:17 +0000, Burri Olivier wrote:

> Dear List,
>
> A While back we heard of the Fiji Update Site concept from Johannes which would be great for us to distribute the few macros and plugins our users have come to enjoy using on our platform.
>
> After a few unsuccessful attempts, we've got it up and running no problem.
>
> I was just curious on whether the updater could add other files to the update site. For instance, we have an ActionBar that contains icons in .png format. We can upload the actionBar to the update site but the icons, if added as a dependency, are considered as an "obsolete/local-only dependency".
>
> Would there be a way to overcome this?
>
> Thanks!
>
> 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
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

Stephan Saalfeld
Sure.  But my guess was that if you upload an additional jar file that
contains e.g.

plugins/actionBar/icons/myIcon1.png
plugins/actionBar/icons/myIcon2.png

shouldn't that be accessible for the ActionBar then?  May be not if it's
enforcing loading them from the file system---but would be nice...

Sorry for unqualified loud thinking :)

Best,
Stephan




On Thu, 2013-01-31 at 11:35 +0000, Burri Olivier wrote:
> plugins/actionBar/icons

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

dscho
In reply to this post by Olivier Burri
Hi Olivier,

On Thu, 31 Jan 2013, Burri Olivier wrote:

> A While back we heard of the Fiji Update Site concept from Johannes
> which would be great for us to distribute the few macros and plugins our
> users have come to enjoy using on our platform.
>
> After a few unsuccessful attempts, we've got it up and running no
> problem.
>
> I was just curious on whether the updater could add other files to the
> update site. For instance, we have an ActionBar that contains icons in
> .png format. We can upload the actionBar to the update site but the
> icons, if added as a dependency, are considered as an
> "obsolete/local-only dependency".
>
> Would there be a way to overcome this?

I guess those icons live in plugins/? The problem with that is that really
only plugins should live in that subdirectory. Any chance this can be
changed to the images/ subdirectory?

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

Alexandre Dufour
In reply to this post by Olivier Burri
Hi Olivier,

On 31 janv. 2013, at 10:17, Burri Olivier wrote:

> Dear List,
>
> A While back we heard of the Fiji Update Site concept from Johannes which would be great for us to distribute the few macros and plugins our users have come to enjoy using on our platform.
>
> After a few unsuccessful attempts, we've got it up and running no problem.

Sorry for not having followed the verge of that idea (I therefore cannot fully understand the technical discussion going on here), but what do you mean by Fiji Update Site concept ? Is it accessible somewhere I can have a look at ? How does it work ?

Cheers
Alexandre
--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

dscho
Hi Alexandre,

On Thu, 31 Jan 2013, Alexandre Dufour wrote:

> On 31 janv. 2013, at 10:17, Burri Olivier wrote:
>
> > A While back we heard of the Fiji Update Site concept from Johannes
> > which would be great for us to distribute the few macros and plugins
> > our users have come to enjoy using on our platform.
> >
> > After a few unsuccessful attempts, we've got it up and running no
> > problem.
>
> Sorry for not having followed the verge of that idea (I therefore cannot
> fully understand the technical discussion going on here), but what do
> you mean by Fiji Update Site concept ? Is it accessible somewhere I can
> have a look at ? How does it work ?

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.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

ctrueden
In reply to this post by Alexandre Dufour
Hi Alexandre,

> what do you mean by Fiji Update Site concept ?

Fiji supports the idea of "update sites," which make distribution and
updates of plugins much easier. Plugin developers can create their own
("third-party") update site, which hosts their plugins [1]. Users can add
these third-party update sites to their Fiji installation [2], so that all
the plugins there get included and updated automatically.

We moved the Updater into ImageJ2 core last year [3] -- but Fiji still uses
it too, of course. See also the ImageJ2 2.0.0-beta1 blog post [4] for more
about update sites.

Personally, I think the Updater is Fiji's single most valuable addition to
ImageJ, since it makes it so much easier to manage all your plugins, extend
ImageJ with more plugins, etc.

Regards,
Curtis

[1] http://fiji.sc/How_to_set_up_and_populate_an_update_site
[2] http://fiji.sc/Update_Sites
[3] http://developer.imagej.net/2012/09/11/imagej-v200-beta4
[4] http://developer.imagej.net/2012/04/09/imagej-v200-beta1


On Thu, Jan 31, 2013 at 9:26 AM, Alexandre Dufour <[hidden email]>wrote:

> Hi Olivier,
>
> On 31 janv. 2013, at 10:17, Burri Olivier wrote:
>
> > Dear List,
> >
> > A While back we heard of the Fiji Update Site concept from Johannes
> which would be great for us to distribute the few macros and plugins our
> users have come to enjoy using on our platform.
> >
> > After a few unsuccessful attempts, we've got it up and running no
> problem.
>
> Sorry for not having followed the verge of that idea (I therefore cannot
> fully understand the technical discussion going on here), but what do you
> mean by Fiji Update Site concept ? Is it accessible somewhere I can have a
> look at ? How does it work ?
>
> Cheers
> Alexandre
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

Alexandre Dufour
In reply to this post by dscho
Hi Johannes, Curtis

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").

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

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

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

Alexandre

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html
Reply | Threaded
Open this post in threaded view
| More
Print post
Permalink

Re: Fiji Update Site: Dependencies

dscho
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