Link fixes

[rleigh-codelibre]

Closes: ome/ome-files-cpp#98

This corrects some long-standing issues in both the C++ and Java reference processing implementations.

• OMEModelObject::link implementations always chained up to their parent before handling the linking themselves. This works, but would result in the parent issuing a warning if it couldn't handle it, despite the child later handling the link. We now chain up only if the child can't handle the link, and issue a warning right at the top if nothing handled it. This solves a number of annoying Java model serialisation warnings which are completely bogus. The same applies for C++.
• C++ OMEXMLMetadataStore addReference calls in setXXXAnnotationRef methods updated to match the Java templates more closely. There are no functional changes. A shared pointer copy is replaced by a cast.

In effect, you will see that setting an AnnotationRef on Detector or any other element derived from ManufacturerSpec will no longer have ManufacturerSpec::link issue a bogus warning. The ome-files-cpp metadata-formatwriter example will no longer issue spurious warnings. This applies to any model object which is derived from another model object, e.g. LightSource, where the reference is handled by the most derived type, or any derived type after the first, where the chaining up will trigger the spurious warning.

For OMERO import, this should remove a large number of the bogus import warnings related to OME-XML metadata which we have seen on e.g. the QA system and other channels over the last few years. LightSource and Shape are notable culprits.

Testing:

• Check the C++ build logs; they will no longer contain [warning] Unable to handle reference of type messages for any of the unit tests.
• Run ome-files examples/metadatastore-formatwriter test.ome.tiff and then tiffinfo or tiffcomment on test.ome.tiff. Check that you get three AnnotationRef elements linking to the three annotations, demonstrating that the reference processing and subsequent serialisation worked correctly.
• Run ome-files info test.ome.tiff --omexml to check this round-trips.
• Check Java with a similar sample for metadata-formatwriter, creating an AnnotationRef on Detector or similar. You'll see the warnings go when built against this ome-model snapshot, but otherwise no other functional changes.

/cc @joshmoore

[rleigh-codelibre]

Copied to GitLab.

Generated source changes are in the pipeline.

[rleigh-codelibre]

See also review note on GitLab.

[rleigh-codelibre]

@mtbc This is where the spurious link/ref warnings originate.

[rleigh-codelibre]

@joshmoore @mtbc Is there anything blocking this reference processing fix being merged? It's a pretty straightforward fix.

[mtbc]

🤷‍♂️ So this can supersede #87? 👍

[rleigh-codelibre]

@mtbc No, they solve separate and unrelated issues. This one prevents warnings being issued when there was no problem, i.e. they are false positives. The other one is actually allowing the storage of invalid data in the model. This one is a trivial change to where the warning is issued. By always chaining up to the parent when the link wasn't handled, we warn only if the root object link method is entered, indicating that no subclass was capable of handling the situation. Thus we only warn about legitimate cases.

[snoopycrimecop]

Conflicting PR. Removed from build BIOFORMATS-push#513. See the console output for more details.
Possible conflicts:

• Upstream changes
  • ome-xml/src/main/cpp/ome/xml/model/detail/OMEModelObject.cpp
  • xsd-fu/templates-cpp/OMEXMLMetadata.template
  • xsd-fu/templates-cpp/OMEXMLModelObject.template

--conflicts

[sbesson]

Closing as this conflicts with the removal of the C++ classes in #111