How to deliver plugins to users? Update site mechanism


Hey guys,

from a recent discussion on github, a question arised which circulates in my head for some time:

How may I deliver custom FIJI plugins to end users in a convenient way?

I mean convenient for users and developers. Just imagine: We often program simple plugins for single users which may evolve to often used powerful and generic plugins or may not. Let’s say we create a plugin every two weeks, which sums up to about 25 per year.

How should I ship them? If I put them all in the same update site, every user using this update site will be overwhelmed at some point. I mean, FIJIs menu structure is hard to overview already.
Alternatively, I can create an update site for every plugin or for categories of plugins. But this makes maintaining the update sites a mess for me.
Is there any alternative?

How do others do that? Any suggestions are appreciated.



IMHO ImageJ update sites is the answer.

  • Regardless of how many times you update a plugin, your end users will get it transparently. They just are notified to update Fiji, which happens every 2 days anyway. This is not very intrusive.
  • Your point with the Fiji menu structure is unrelated. It would require another difficult discussion.
  • You are sure not to bother other end users: if they don’t want your plugin, they can unsubscribe from your update site.


Everyone knows about this page, right?

Discusses, compares and recommends options.

Some of this is due to the (current) lack of menu standardization. I know that originally, Johannes put a lot of time and effort into organizing the menus. I have not made time for doing that, so in recent years the menus have gotten messier. But help in reorganizing them is welcome—moving a command to a new menu, as long as it keeps the same name, should not break backwards compatibility with macros and scripts.

As for a proliferation of too many plugins: you are not the first to complain about that. Ultimately, we may move toward more granular selection and installation of plugins, like in Icy—but that will still be a long time in coming.


One other comment, @haesleinhuepf. Using an update site should have no disadvantage over manual drag-and-drop of plugin JARs, because the Updater allows you to individually mark JARs for inclusion or exclusion. So even if you have 500 plugins on an update site, if they are organized into many JAR files, your users can cherry-pick them, while still enabling the Updater to do its job of keeping the installed ones up to date. There really is not (as far as I see) any disadvantage there.


That’s nice! I didn’t know that! :slight_smile:

Maybe that’s the answer to my question. I’ll give it a try.

By the way: My post on top was no complain. Discussing FIJIs menu structure was not my intention :wink:

I just wanted to know how others are dealing with the fact that distribution of many, tiny, independent plugins may be confusing for users and/or developers.


I suggest organizing them into a tiered menu structure, all based under a single element in Plugins. Try to avoid more than 10 items at any one layer. Then users will not feel so overwhelmed, and they can explore.

This is a general problem with Fiji’s “more parts on the table” approach. I don’t think anyone has a perfect answer. Personally, I favor shipping more things to users by default, so that they can be found e.g. using the Command Finder. But as @mdoube puts it, they need to be “under the table tidily away in a drawer”. A happy medium could be that in the future, all items appear in the menus but the JARs are not actually installed until the first time the command is run. This is more complex though, and would come with its own issues: e.g., needing network access the first time you run someone’s script that uses new commands. Maybe this would be overall better though.


Or - you could make plugins in the Updater list discoverable by the Command Finder, so that if you go looking for, say, a segmentation technique, Command Finder says, such a thing is available, but you need to install it first, then takes you to the updater to get it.

@haesleinhuepf - we’re finding GitHub/Maven/Jenkins/(Updater) pretty good to join up all this stuff for BoneJ2: @rimadoma has set up automated builds that will eventually feed straight forwards to users, with artefacts already available for developers. It’s a massive paradigm shift from the old way, much more joined-up and painless.


Cool @mdoube and @rimadoma ! I like the “painless” aspect.

We’re just planning to do a similar approach as well. But we’re not sure how to do it exactly. So let me add some questions:

Do you ship every little bugfix and every little change through this deployment machinery?

What about having stable releases and nightly builds?

Is your strategy comparable to those explained on that website?

Thank you all for this fruitfull discussion. I’m learning a lot!


@haesleinhuepf Are you coming to the Konstanz hackathon in July? If so, this would be a good time to go over how to automate some of that stuff.


I’m afraid, I cannot join this time :frowning:


Ah, too bad!

There are quite a few different ways to manage uploads to an ImageJ update site. The gist is: there is a command-line updater, and you can use it to automate uploads of your files.

For example, the Bio-Formats update site is driven by this Jenkins job which calls the script, which calls the script.

Whether it is worth setting this up really depends on how often you update your plugins.

Note that that section describes ways to cut Maven releases, which is distinct from uploading to an update site. Which part of the process are you wondering about?

Update personal update site from command line

We just introduced JUnit test automation using an in-house jenkins for the more important projects and collections of plugins. We have a development branch (for testing) and a master branch (for releases). I could imagine to utilize jenkins to update an update site if master was updated and testing succeedes.

I will have a closer look at the bioformats jenkins job…

Again: Thanks a lot for your input!


Hello @haesleinhuepf,

Do you ship every little bugfix and every little change through this deployment machinery?
Yes, but we don’t initiate the auto build with every commit. It starts only when there’s a commit to the master branch of our repo. The way we work is that if we want to implement a new feature / add a bugfix we’ll make a new branch, work on that until it’s finished and then merge it to the master branch, which initiates a deployment. I also have Maven on my own computer, and check that everything builds OK before merging. One thing to note is that you can’t have calls to GUI in your unit tests. Those will break the build on the Jenkins server.

What about having stable releases and nightly builds?
Our Jenkins job doesn’t have nightly build. Note that the job builds new versions of the Maven artefacts for developers. When you want to cut a release for users to the update site, you initiate that manually. Were not there yet, but basically we’ll just cut a release every time we feel there are enough new stable features. Maven artefacts have two kinds of versions: releases and SNAPSHOTS. The releases must not change after they are out. SNAPSHOT versions are development versions where the API and implementation can still wildly change. The artefact version numbering should follow semantic versioning. We’re still in the early 0.x.x numbering with BoneJ2 where all bets are off :wink:

Is your strategy comparable to those explained on that website?
Yes, we’re following the double push strategy. There we comment out the modules that are not getting updated in the current release. Here’s an example (check the previous commit too).

Best Regards,
Richard Domander


Hey guys,

I was just trying to setup a procedure using the mentioned steps. However, I’m running into trouble with user accounts and update sites. If I try to update my update site (User Haseleinhuepf), ImageJ continues asking me for username and password. I changed it (successfully) on that website:

and it ImageJ still asks for username and password. For testing I created a new user Haesleinhuepftest on the wiki and when trying to upload something to his update site, ImageJ complains with the error message “Could not initialize the personal update site.” When I go to the change password website linked above, I get this error message, even though I’m logged in:

Are the others able to update their update sites?

@ctrueden Could you or one of your IT guys please check if there is something wrong with the authentication to the update sites?



@aneevel Please take a look.



When adding the new “my update site”, FIJI’s console says:

action: changeuploadpassword
Error setting upload password for user 'Haesleinhuepftest': Permission denied


Hey guys,

I’m having again a (related) issue with the update sites.
Scenario 1:

  • I have a plugin called MyPlugin_.jar
  • I upload it to the update site via the ImageJ Updater.
  • If I update the jar file, the updater recognizes that and allows me to upload it to the update site.
    This works fine, however,…

Scenario 2:

  • I have a plugin called MyPlugin_-1.0.0.jar
  • I upload it to the update site via Image Updater.
  • If I replace the plugin with MyPlugin_-1.0.1.jar (newer version), the ImageJ Updater appears not to recognize correctly, that this is a newer version of the first plugin. It does not even allow me to upload it to the update site.
    The only way we found to update the update site is this complicated one:
  • Delete both versions of MyPlugin from the plugin directory.
  • Run FIJI and the Updater
  • Use the updater to “Mark obsolete (update site)” the [missing] plugin
  • Close FIJI
  • Copy version 1.0.1 to the plugin folder
  • Run FIJI to upload the new version of the plugin to the update site.

This is so anoying complicated… Is this intended? Is there a better way to do this?

Thanks for any hints!



I think there shall be a different approach to add update sites, since the fiji updater is too fragile and any error breaks the launcher. Right now i have to launch the updater to manage user sites, this shall be changed to add them as user request. So there is a need to add a menu item for launching the site manager.


Not intended, and not my experience. Did you delete the 1.0.0 version first before launching Fiji? There should be exactly one version present upon launch of Fiji: the new 1.0.1 one. And then the updater is supposed to detect that it is the same plugin, just at a different version. If that does not work, definitely let us know.

Why don’t you use the command line updater?


precisely, but as a menu item, not as an annoying cmd line thing, remember there are windows users :wink: I can easily add this to my fiji, but I am saying this shall be official approach.