GeezerVison

I think this will wreak havoc with the ops matcher, unfortunately. Even though the Logger is optional, it is still a parameter, unlike LogService which is ignored by the ops matching framework. The Logger should be completely invisible to ops, and never appear in any op signature.

Also, we do still need the LoggerPreprocessor, for scripts, since a script could have a Logger parameter, and the context injection will not handle it. This is the same reason we have the ServicePreprocessor still.

Even though the Logger is optional, it is still a parameter, unlike LogService which is ignored by the ops matching framework. The Logger should be completely invisible to ops, and never appear in any op signature.

I have a different opinion, I want the Logger to be an optional parameter. Let's assume: The caller of an op has a sophisticated UI with an integrated logging panel. The logging panel should show the log messages of the op. This can be achieved by providing a prepared Logger as parameter to the op.

Also, we do still need the LoggerPreprocessor, for scripts, since a script could have a Logger parameter, and the context injection will not handle it. This is the same reason we have the ServicePreprocessor still.
Merge state

Ok, I will restore the LoggerPreprocessor

I want the Logger to be an optional parameter.

OK. There will be consequences though, is all I am saying. I assume you want existing ops that use LogService parameter to instead use Logger:

• src/main/java/net/imagej/ops/commands/filter/FrangiVesselness.java
• src/main/java/net/imagej/ops/help/HelpCandidates.java
• src/main/java/net/imagej/ops/image/equation/DefaultEquation.java
• src/main/java/net/imagej/ops/thread/chunker/ChunkerInterleaved.java
• src/main/java/net/imagej/ops/thread/chunker/DefaultChunker.java
• src/main/java/net/imagej/ops/threshold/rosin/ComputeRosinThreshold.java

These ops will all need their namespace methods updated to include the Logger. All existing code that relied on a certain number and order of parameters for them will break, because there is now a new Logger parameter, which must either be passed, or set to null. (Only if there are no other optional parameters "to the right" will existing code still work as expected, with null logger.) Furthermore, all of these ops assume the LogService (now Logger) is non-null, which it may not necessarily be now, so they all need to wrap all log statements with if (log != null).

Ok, the consequences your are describing clearly call for a better solution, than what I suggested.

CC @gselzer: next year when we take stock of the current Ops progress, let's discuss this Logger issue. Now that the Ops framework is fundamentally not built on Command/Module anymore, this PR may be easier to integrate into the SciJava framework in a backwards-compatible way. Ideally, op implementations should be able to declare a @Parameter Logger for logging, without it affecting the function signature, in the same way they can declare service parameters.