Reason is that the class named command:de.mpi.... cannot be found. That kind of makes sense, as the "command:" stringy at the beginning disturbs. I found a way to fix the bug by removing "command:" here:
But I guess, that’s not a good idea. Do you have an idea, where scijava gets confused between identifiers and classnames? Hint: we are working with a class derived from InteractiveCommand, I assume it has something to do with that…
Yes, it’s the SCF-MPI-CBG update site. And the menu you find in SCF > Labeling > Interactive H_Watershed. Just open any image and click this menu. The error message shows up and also the plugin dialog. The dialog also works properly…
@haesleinhuepf TL;DR I have a candidate fix committed to the master branch of imagej-legacy. You can download and test the latest imagej-legacy snaphsot.
Explanation: the ImageJ Legacy component adds a hook to intercept ImageJ 1.x’s plugin execution, so that ImageJ2-style commands can be handled. The LegacyService.runLegacyCompatibleCommand(String className) method is called first, and only if it returns null (which is supposed to happen only when the className in question is not an ImageJ2-style identifier) does the code path fall back to ImageJ1’s normal plugin handling routine.
Unfortunately, there is a case where null is returned even though ImageJ2 does handle command execution. So then both ImageJ2 and ImageJ1 try handling the command. The error dialog is ImageJ1 failing to do so.
So when is null returned? See here; it’s a hack to preserve backwards compatibility. The gist is that it happens when the command in question implements Module directly.
I believe the following commit has fixed the problem:
But it would be nice for people to test it with some usual workflows, including execution of both ImageJ1- and ImageJ2-style plugins, before we cut a new release.
Hey @ctrueden, great. I just tested and can confirm that the bug is gone! Thanks a lot!
we have here a little change deep inside ImageJ. We would need some volunteers to test the new imagej-legacy.jar file in daily routine. Please download it, put it in the jars subdirectory of Fiji, remove the old one and restart Fiji. For testing, just work as usual and maybe run some of your ImageJ macros which use the run(); command often. Question: Are menus executions ignored? Are some menu executed twice? Are macros and scripts opened as usual?
I’ve downloaded the updated image-legacy.jar and run some scripts which call a variety of plugins via run() command (mostly IJ1, few IJ2). So far everything works as expected. That’s not a complete study of course, but so far so good.
Can btw confirm that the error message has disappeared which is great!
Since core updates are rely solely on me right now, the feasibility of releasing updates is at the mercy of my workload. At the moment, I have several high-priority “fires” on top of my usual duties, making it very difficult for me to find time to release Fiji updates in a timely manner. I thought I would be able to take care of a small update last week, but I was wrong—too many other things happening, and I missed my chance. I won’t be able to work on doing releases + updates again until April; in the meantime, we will continue to have a buggy search bar, and lack of new Script Editor features. Hopefully this year, together with @turekg, we can establish some more automation to make updating Fiji components easier, faster and less disruptive.