Very much like #13, but instead of starting ImageJ server in a separate process, it should be started in the same JVM. (See https://github.com/maarzt/scijava-parallel-examples/blob/master/src/main/java/org/scijava/parallel/examples/ExampleExecute.java) This would very simplify debugging. If the developer runs the program in debug mode, than the ImageJ server runs in the same JVM also in debug mode, breakpoints and everything becomes possible.
TODO: Create a DebugParadigms.startImageJServerInThread() that starts ImageJ server in a thread and returns a fitting paradigm.
Other advantages:
- No FIJI installation needed
- No need to copy the remote commands into the FIJI installation.
- Remote commands can be debuged.
Problem:
- The paradigm can not be part of scijava-parallel, because this would add an dependency to imagej-server. This code need to be an extra repository, maybe in scijava-parallel-example.
Very much like #13, but instead of starting ImageJ server in a separate process, it should be started in the same JVM. (See https://github.com/maarzt/scijava-parallel-examples/blob/master/src/main/java/org/scijava/parallel/examples/ExampleExecute.java) This would very simplify debugging. If the developer runs the program in debug mode, than the ImageJ server runs in the same JVM also in debug mode, breakpoints and everything becomes possible.
TODO: Create a DebugParadigms.startImageJServerInThread() that starts ImageJ server in a thread and returns a fitting paradigm.
Other advantages:
Problem: