Ensure imglib2-algorithm can declare all its functionality as ops in a dependency-light (or even dependency-free—e.g. XML? Spring? see #55) way.

Of course, the imglib2-algorithm-side work is not technically part of scijava-ops, but we want to be 100% confident the architecture will support this.

We need to decide how to consume imglib2-algorithm from Ops. Possible approaches:

1. [CURRENT] Leave imglib2-algorithm alone. Wrap all algorithms in imagej-ops.
   • Pro: No changes needed to imglib2-algorithm. No new dependencies.
   • Con: Tons of boilerplate. Does not evolve with additions to imglib2-algorithm. Extra maintainer effort from people less close to the imglib2 project.
2. ServiceLoader. Change imglib2-algorithm to:
   • Annotate static methods as @OpMethod / @OpField of an OpCollection.
   • Make classes implement the correct functional interface.
   • Declare all implementations according to ServiceLoader mechanism (e.g. for Java 9+, in module-info.java).
   • Pro: Automatically expose algorithms as ops for the matcher, without depending on the matcher!
   • Con: Dependency on ops functional interfaces (function, computer, inplace). Need to manually edit module-info.java to declare your op implementations (potential action-at-a-distance errors waiting to happen)—unless we impose an additional compile-time indexing mechanism of some kind.
3. ServiceLoader with compile-time indexing.
   • As (2) above, but with scijava-indexer, or Spring indexer, or something, so you don’t have to maintain your module-info manually.
   • Pro: Reduce action-at-a-distance errors/skew.
   • Con: Another compile-dependency (but maybe can be hidden in pom-scijava! Depends where the annotation interface(s) being used live—research needed).
   • This approach can be “added on” to B perhaps, and can wait to explore till later.
4. Go all-in on Spring, with all algorithms discoverable via Spring-based discovery (which mechanism? TBD).
   • Con: Adds big dependencies to imglib2-algorithm. (Or does it?)
   • Pro: Unified framework across more of our ecosystem, as SciJava 3 adopts Spring in general for its context-aware layers.

Additional notes:

• Make scijava-function component with ONLY the functional interfaces.
  • org.scijava.ops.function -> org.scijava.function
  • NO dependency on ServiceLoader. Just paves the way.
  • OpCollection and @OpMethod and @OpField and @OpDependency?
    • @OpMethod declares functional type—but this could potentially be inferred if we instead have people annotate @Container and @Mutable on their method parameters.
      • Another potential advantage of this could be that your component does not need to depend on org.scijava.function at all, then—only on the @Container + @Mutable annotation classes… but see next point about op name declaration...
      • Those annotations could live in scijava-ops-api in that case?
  • @OpMethod and @OpField declare fully qualified op name including namespace—maybe no elegant way to get around this.
• As an experiment, see if imglib2-algorithm can depend on scijava-function, and the algorithms there can implement the right functional interface, and module-info can declare those algorithms as implementations.
• Then see if you can depend on imglib2-algorithm in a downstream project (e.g. imagej-ops2) and discover all the imglib2-algorithm implementations as Ops!
• Once we have working options, present them to the ImgLib2 maintainers to discuss tradeoffs.