Fiji updates break plugins distributed through the Fiji update mechanism

Tags: #<Tag:0x00007fb87df3d990> #<Tag:0x00007fb87df3d800>


Recently, a lab member showed me that one of my plugins distributed through the Fiji updates site no longer worked. He ran into a run-time error caused by Fiji updating the jfreechart jar to a newer version, which had moved one of the api functions to a new location. Easily fixed, however, this problem shows how easily things get broken. It is extremely painful that updating all code through the Fiji updater can lead to problems that were easily caught by the compiler.

It seems that there are various ways of dealing with this. For starters, with every change to pom-scijava, an email could go out to all maintainers of plugins, asking to update their poms, compile their code, and push out a new version if anything broke. I can certainly think of ways of doing this that would be less work for plugin maintainers and more automated, but more work for the Fiji maintainers.


Nobody cares? Some more characters since 20 characters is the minimum?!


Hi @nicost

I’m interested in this issue too. I’ve been working with javacpp the last few months. However it seems Fiji is shipping with an old version of javacpp. I’m not really sure what the protocol is, if I want to distribute a plugin that needs a newer version of javacpp. Who do I contact? How do we switch to a new version? What if the new version breaks an existing plugin? So you are asking a good question. How do plugin writers coordinate updates of shared jars??


A lot of us do, and there are several related cases where “version skew” triggered by an update of one of the core update sites (ImageJ, Fiji, Java-8) led to breakage of some other update site (or where a third-party update sites shipped a jar that was rendered outdated by an update on a core site):

The reason you don’t get a lot of replies might simply be that there is currently no better solution.

@ctrueden has been working on a script called melting-pot that is supposed to test how well all components go together:

But this might not solve the problem that different update sites can still ship their own conflicting jars.

It was also discussed to improve the update mechanism to let maven automatically upload releases and their dependencies to update sites, but nobody had time to pursue this further, as far as I know.

You can start watching the pom-scijava repository, then you should get updated about every change and can test it for yourself. Does that help?


I do care very much about this issue, but currently do not have time to respond in detail. So here are a couple of quick points:

The script will indeed be a way to reduce, or at least be more practively aware of, future breakages. My idea is that third-party update sites can “opt in” to inclusion in a “big melting pot” job that runs regularly—they would just need to conform to certain technical requirements (using Maven with all versions declared as version properties—otherwise the melting pot won’t work properly).

The JFreeChart breakage was my fault, because I decided to update it. I am sorry. @tinevez and I went through shortly thereafter and updated all of Fiji to fix internal breakages, but I neglected to send any warning or announcement to the greater community. I guess I underestimated how many people were using JFreeChart with their plugins. I can try to do better in the future about notification in such circumstances, but I think this will always be a problem to some extent, with a plugin-based system like ImageJ.

I have strongly considered other solutions to sidestep the version incompatibility issue; see this thread for details:


As I found via (using the GitHub button), javacpp seems to be used by three projects within the SciJava/ImageJ universe:

Currently, the version of javacpp isn’t managed in pom-scijava, so I guess the steps to make this consistent across components would include:

  • Add a version property to pom-scijava:

      <!-- JavaCPP - -->
  • Update fiji/H5J_Loader_Plugin to:

    • have an explicit dependency on javacpp (as it directly imports classes from there)
    • use the managed version from pom-scijava
  • Update scifio/scifio-javacv by increasing the version of the ffmpeg dependency

I think a forum topic like this one is a good place to get the ball rolling…

Use openCV within Jython macro

Thanks a lot @imagejan, this is very, very, helpful.


@bnorthan I can push on getting javacpp managed by pom-scijava, if this is helpful to you. Just bug me some more about it if so. :slight_smile:


Thanks @ctrueden at some point in the next couple of months, I want to distribute the YacuDecu GPU deconvolution wrapper, however there are some other things (namely a clean windows build) I need to get done before I am ready for that. I’ll let you know when I am almost there.