

But I feel uneasy about introducing yet another imagej component, especially one housing such a central piece of functionality.Īnother 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.

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. One solution to this dilemma would be to reduce the number of services exposed by the gateway in a type-safe way. 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(). imagej-common, because the gateway depends on services beyond only those in imagej-common and scijava-common. Unfortunately, it is not possible to move the gateway to e.g. 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. Sorry I dropped the ball on following up on this.
