Weird Stitching UI behavior

[ctrueden]

@ehrenfeu wrote:

The stitching UI behaves very weird after being started by a macro command once.

Steps to reproduce (tested on Linux and Win7 x64):

• download a fresh copy of Fiji
• start
• run the stitcher via Plugins > Stitching > Grid/Collection stitching
• "normal" dialog comes up (notice the graphic representation of the selected settings)
• hit "Cancel"
• File > New > Script
• Language > ImageJ Macro
• enter run("Grid/Collection stitching");
• hit "Run"
• dialog doesn't show the graphical representation, AND allows for invalid combinations of options (e.g. "Positions from file" and "Right & Down")

I could live with the temporary workaround of not calling the stitcher from a macro for a while, however after starting it using the above described command once, the behavior stays like this. I.e. you can't run it correctly from the Plugins menu anymore either.

Cheers
~Niko

@StephanPreibisch wrote:

In order to allow the macro recording to work, it shows a simpler version when called from a macro, this is on purpose, otherwise it would not work. Usually, it is supposed to be called with a lot of parameters so that it runs automatically.

However, when running the plugin afterwards from the menu, it still thinks that it is in plugin mode. The bug seems to be on the ImageJ/Fiji side, as the call

IJ.isMacro()

still returns true although it is called through the menu. Does anybody have an idea how this can happen?

@rasband wrote:

Stephan,

You could try using IJ.macroRunning() instead of IJ.isMacro(). Here is the source for these two methods:

/** Returns true if the run(), open() or newImage() method is executing. */
public static boolean macroRunning() {
  return macroRunning;
}

/** Returns true if a macro is running, or if the run(),
    open() or newImage() method is executing. */
public static boolean isMacro() {
  return macroRunning || Interpreter.getInstance()!=null;
}

Migrated-From: http://fiji.sc/bugzilla/show_bug.cgi?id=685

[dscho]

I wonder whether @StephanPreibisch is notified of these issues. After all, he is listed as maintainer on the Fiji Wiki.

[StephanPreibisch]

Yes, I got them, now that they say [Stitching] it is also more obvious that it is meant for me :)

[ctrueden]

@ehrenfeu: If you clone this repository, then change instances of IJ.isMacro() to IJ.macroRunning() as suggested by @rasband, then rebuild (mvn package) and retest (copy target/Stitching_-2.0.0-SNAPSHOT into your $FIJI_HOME/plugins), does it fix the problem you reported above?

[StephanPreibisch]

that does fix it, I just tested it, but my commit of course went into nirvana as the stitching is gone now from the main fiji repository, which I forgot ... sorry, there is too much going on right now. I will try to catch up how this external plugin thing works later.

[ctrueden]

No worries @StephanPreibisch, I took care of it.

For future reference, all you need to do is git clone git@github.com:fiji/Stitching and then just work in that codebase instead. Import it into Eclipse and you should be good to go, same as before.

[StephanPreibisch]

hi @ctrueden, thanks, we did the same commit now :) By figuring out I meant specifically how to put it into the Fiji uploader now that it is not anymore in the fiji project ... sorry for being so unspecific ...

[dscho]

@StephanPreibisch you still build in the Fiji clone as before -- after the Jenkins job completed, of course -- and then upload from there. Since you did not make a release version (which makes it an unreproducible version) it is a -SNAPSHOT version, so you might want to use mvn -U to make sure that plugins/Stitching-2.0.0-SNAPSHOT.jar is actually updated. After that, you upload as before.

If that is too involved for you, you could also call mvn -Dimagej.app.directory=/path/to/your/Fiji.app in your Stitching clone. In that case, the plugins/Stitching-2.0.0-SNAPSHOT.jar will disagree with every deployed version, though.

[StephanPreibisch]

Cool, thanks Johannes, I will try that out! Just out of curiosity, Fiji knows that the Stitching exists because it is registered as a Maven artifact?

[dscho]

@StephanPreibisch it is more like Maven knows about that Stitching artifact because it was specified in the pom.xml file. And Fiji is built using Maven.

[ehrenfeu]

Thanks guys for testing the fix suggested by @rasband. I didn't have a chance to do it myself yet. Is it already merged into the latest Fiji updates?

[StephanPreibisch]

It is for now just in the newest version of git: https://github.com/fiji/Stitching

I will try to upload it to the Fiji soon ... I did not do that yet since it is an external plugin and I need to figure out how it works. But it should be straight forward. I will start to add version numbers to the output to verify it is the current version.

Cheers,
Stephan

[dscho]

@StephanPreibisch oh, I thought it was obvious that external plugins are still core Fiji plugins and nothing has changed in the procedure how to upload them? You simply call ./Build.sh in your Fiji checkout -- as before! -- test it, verifying that the fix actually made it there, and then use the Fiji updater to upload the relevant files...

[StephanPreibisch]

Oh cool, I will try that tomorrow ... thanks Johannes

[StephanPreibisch]

Hi Johannes, I built the Stitching with mvn on my computer (after pushing everything to github:master) and triggered it on Jenkins by clicking build now. Afterwards I built Fiji using ./Build.sh, but it did not fetch the newest version of the Stitching_.jar. Do I just have to wait or is there some trigger necessary?

Thanks a lot the advice, Steffi

[StephanPreibisch]

mvn -U
did the job (as you pointed out above actually) ... but it produced (compared to ./Build.sh) two compile errors that somehow do not seem to interfere with the build:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2:34.259s
[INFO] Finished at: Sat Jan 18 14:48:54 EST 2014
[INFO] Final Memory: 57M/114M
[INFO] ------------------------------------------------------------------------

Here are the errors:

[INFO] Created service: io.scif.services.DefaultInitializeService
Hello (bare) world!
Running Test PlugIn
Hello (test) world!
Running Another Bare PlugIn
Hello (another bare) world!
Running Missing Dependency
java.lang.NoClassDefFoundError: test/Dependency
at test.Missing_Dependency.run(Missing_Dependency.java:8)
at ij.IJ.runUserPlugIn(IJ.java:196)
at ij.IJ.runPlugIn(IJ.java:160)
at ij.Executer.runCommand(Executer.java:131)
at ij.Executer.run(Executer.java:64)
at ij.IJ.run(IJ.java:266)
at ij.IJ.run(IJ.java:244)
at ij.macro.Functions.doRun(Functions.java:592)
at ij.macro.Functions.doFunction(Functions.java:89)
at ij.macro.Interpreter.doStatement(Interpreter.java:226)
at ij.macro.Interpreter.doStatements(Interpreter.java:214)
at ij.macro.Interpreter.run(Interpreter.java:111)
at ij.macro.Interpreter.run(Interpreter.java:81)
at ij.macro.Interpreter.run(Interpreter.java:92)
at ij.plugin.Macro_Runner.runMacro(Macro_Runner.java:123)
at ij.IJ.runMacro(IJ.java:112)
at ij.IJ.runMacro(IJ.java:101)
at ij.ImageJ.main(ImageJ.java:683)
at fiji.Main.main(Main.java:154)
at BarePluginsIT.assertPlugInOutput(BarePluginsIT.java:245)
at BarePluginsIT.run(BarePluginsIT.java:171)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at BarePluginsIT.testBarePlugins(BarePluginsIT.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.lang.ClassNotFoundException: Blacklisted: test.Dependency
at BarePluginsIT$1.loadClass(BarePluginsIT.java:114)
... 48 more

Running Changed Method Signature
There was a problem with the class ij.ImageJ which can be found here:
/Users/preibischs/.m2/repository/net/imagej/ij/1.48p/ij-1.48p.jar
/users/preibischs/workspace/fiji/src-plugins/fiji-compat/target/target/ijRoot/plugins/ij/ImageJ.class

WARNING: multiple locations found!
java.lang.NoSuchMethodError: ij.ImageJ.main(D)V
at Changed_Method_Signature.run(Changed_Method_Signature.java)
at ij.IJ.runUserPlugIn(IJ.java:196)
at ij.IJ.runPlugIn(IJ.java:160)
at ij.Executer.runCommand(Executer.java:131)
at ij.Executer.run(Executer.java:64)
at ij.IJ.run(IJ.java:266)
at ij.IJ.run(IJ.java:244)
at ij.macro.Functions.doRun(Functions.java:592)
at ij.macro.Functions.doFunction(Functions.java:89)
at ij.macro.Interpreter.doStatement(Interpreter.java:226)
at ij.macro.Interpreter.doStatements(Interpreter.java:214)
at ij.macro.Interpreter.run(Interpreter.java:111)
at ij.macro.Interpreter.run(Interpreter.java:81)
at ij.macro.Interpreter.run(Interpreter.java:92)
at ij.plugin.Macro_Runner.runMacro(Macro_Runner.java:123)
at ij.IJ.runMacro(IJ.java:112)
at ij.IJ.runMacro(IJ.java:101)
at ij.ImageJ.main(ImageJ.java:683)
at fiji.Main.main(Main.java:154)
at BarePluginsIT.assertPlugInOutput(BarePluginsIT.java:245)
at BarePluginsIT.run(BarePluginsIT.java:172)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at BarePluginsIT.testBarePlugins(BarePluginsIT.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)

Could not find method ij.ImageJ.main(D)V
(See Log for details)

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.274 sec - in BarePluginsIT

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[StephanPreibisch]

Done, Stitching uploaded to the Fiji Server! These external plugins are very nice :)

[dscho]

Pointing out that both failures happen in fiji-compat's integration tests would have been helpful. It is funny, however, to see that the build still succeeds, no? The reason is that the integration test -- as is one of the purposes of integration tests (as opposed to unit tests) -- is there to verify that certain things fail. As here: in both cases, we want certain scenarios to produce sensible error messages, and that is exactly what happens, and therefore everything is groovy.

In the future, though, it would be good to keep in mind that Fiji is a huge project and that a little more analysis is more than just helpful when reporting problems. If I would not have had to sift through the log to find the class name, then to find where that class name is used in Fiji, it would have saved me a lot of time (I know, I am the only person caring about my own time, why should anybody else care, but I really do!).

[StephanPreibisch]

Sorry Johannes, even after your very helpful explanation it is not obvious to me from the output that this is an integration test that is supposed to fail when going through the logs. I know that now and I will understand it better in the future.
Please keep in mind that for me Maven is still some kind of blackbox ... I try to follow what you guys suggest and it works out great. But I still do not really understand what is going on under the hood.

Sorry for not pasting more source code, that was not good, the entire output is gigantic and I tried to limit it to a range that I thought would be meaningful - which was obviously wrong :)

Thanks anyways again for your help again!
Steffi