Including `ImageJ` gateway

[hadim]

See this https://github.com/imagej/imagej-scripting/pull/16 for the detail of the discussion.

[ctrueden]

Sorry I dropped the ball on following up on this. As a refresher: this issue is intended to document the fact that imagej-scripting cannot depend on imagej, and therefore the ImageJ gateway cannot be used in any scripts here in imagej-scripting.

Unfortunately, it is not possible to move the net.imagej.ImageJ gateway to e.g. imagej-common, because the gateway depends on services beyond only those in imagej-common and scijava-common. For example, it exposes the NotebookService from imagej-notebook via the ij.notebook() method, the OpService from imagej-ops via ij.ops(), and a SCIFIO gateway via ij.scifio().

One solution to this dilemma would be to reduce the number of services exposed by the gateway in a type-safe way. Another would be to make a new imagej-gateway component with dependencies on all the components housing services it exposes, and make imagej-scripting depend on imagej-gateway, and then imagej could depend on imagej-gateway and imagej-scripting. But I feel uneasy about introducing yet another imagej component, especially one housing such a central piece of functionality.

Another solution would be to remove imagej-scripting from the imagej component's runtime dependencies, in favor of a new imagej-app component (probably committed to imagej/imagej in an app subdirectory, rather than cluttering up GitHub, since nothing should ever depend on it) that assembles everything intended for distribution with core ImageJ2. People who depend on net.imagej:imagej in e.g. a Jupyter notebook are unlikely to care about receiving the script templates that live here in imagej-scripting. But I think the ImageJ core application distribution should include them. And the imagej-scripting component is not alone here—there may be other runtime-scoped components (imagej-plugins-*? imagej-deprecated?) that are not always appropriate or desired to be brought in.

What do you think? Shall we make imagej-app and use that to build the ImageJ2 distribution, and reduce the dependencies of imagej? Then imagej-scripting could depend on imagej and imagej-app could depend on imagej-scripting.

Any other ideas to solve this issue?

[hadim]

That is a very old issue here :-)

Well, I don't have a strong feeling about it and as always I think you are in a better position than me to shape the imageJ packages infrastructure. An imagej-app that include imagej and imagej-scripting makes sense to me. Especially if it lives in imagej/imagej since it's gonna be one less repo for you to handle.

Will that imagej-app component be included in Fiji? Since you are talking only about core imageJ2, I just want to make sure.

[ctrueden]

Will that imagej-app component be included in Fiji? Since you are talking only about core imageJ2, I just want to make sure.

Good question. My idea was that imagej-app would not be a published component on any remote repository, but only used internally to package up the ImageJ distribution—in which case, Fiji would not be able to depend on it. Instead, the sc.fiji:fiji component would need to manually add all the runtime dependencies it wants included, the same way that imagej-app does. That is kind of clunky, but the fact is that when someone adds net.imagej:imagej onto their classpath, what they want to inherit there can differ substantially from person to person. Some people want a kitchen sink, while others do not...

[hadim]

Ok, I understand. But in that case, template scripts in the Fiji script editor will disappear? Or am I missing something?

[ctrueden]

in that case, template scripts in the Fiji script editor will disappear?

That is a good point: if this proposal were implemented, and then we launched ImageJ with jrun net.imagej:imagej, there would be a more stripped-down ImageJ without templates in the Script Editor's Templates menu, yeah. Which I agree is undesirable.

So then we are back where we started: net.imagej:imagej should depend on imagej-scripting in order to include the templates in the Script Editor, but then those templates cannot use net.imagej.ImageJ unless we created a separate imagej-gateway component for imagej-scripting to depend on.

I don't have a better answer. I think imagej-gateway is the proper solution, but I don't like it. Right now we conflate a few different things into net.imagej:imagej for convenience.

The only other idea that comes to mind is to merge imagej-scripting into the imagej repository itself. I.e.: conflate one more thing into it! It would work...

[imagejan]

But in that case, template scripts in the Fiji script editor will disappear?

No, fiji/fiji could still depend on imagej-scripting, just as well as imagej-app would depend on imagej-scripting. So it'd just result in a few duplicate lines of xml in a pom, no?

[hadim]

If @imagejan solution is ok then let's go for that. If it isn't then we can still remove ij() from the script.