With 5da8173, I removed the progress reporting from the DefaultOpEnvironment's op discovery, because it was failing the OpRegressionTest on one of my systems. Investigation shone light onto three distinct issues, the first of which is #228, which I believe is a cascading failure triggered by the second and third issues, described here. First, snakeyaml rejects a mangled scijava-ops-image/target/test-classes/ops.yaml file:
Caused by: java.lang.ExceptionInInitializerError: Exception
org.yaml.snakeyaml.scanner.ScannerException: while scanning for the
next token; found character '@' that cannot start any token.
(Do not use @ for indentation); in 'reader', line 26008, column 2:
{@code <C>}
^ [in thread "main"]
at [email protected]/org.yaml.snakeyaml.scanner.ScannerImpl.fetchMoreTokens(ScannerImpl.java:445)
...
at [email protected]/org.yaml.snakeyaml.Yaml.load(Yaml.java:434)
at org.scijava.ops.engine@0-SNAPSHOT/org.scijava.ops.engine.yaml.impl.YAMLOpInfoDiscoverer.parse(YAMLOpInfoDiscoverer.java:104)
at org.scijava.ops.engine@0-SNAPSHOT/org.scijava.ops.engine.yaml.impl.YAMLOpInfoDiscoverer.lambda$discover$0(YAMLOpInfoDiscoverer.java:78)
The mangling takes the form of a rogue string {@code <C>} on its own line with no indentation, which appears to have overwritten some number of other lines of YAML, leading to improper indentation. (I tried diffing against a properly merged ops.yaml on an unaffected system, but the scijava-ops-indexer does not sort the op blocks, leading to ordering inconsistency, which makes diffing ineffective.)
I suspect the mangling is rooted in a third issue: there is a Ruby script present in the Maven build infrastructure that gets executed using script-maven-plugin, which might be the culprit. But further investigation is needed: it is suspicious that with the removal of progress reporting from DefaultOpEnvironment construction (5da8173, which works around #228), the YAML parsing issue seems to disappear—but it is hard to believe that these two things could actually be related...