build: add AbstractXMLReader to mirth-client-core

[tonygermano]

This class was not available to the client, but it is required to serialize transformer message templates to the message tree view.

[github-actions]

Test Results

  105 files  ±0    202 suites  ±0   7m 1s ⏱️ + 1m 15s
  633 tests ±0    633 ✅ ±0  0 💤 ±0  0 ❌ ±0 
1 266 runs  ±0  1 266 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit df7bad7. ± Comparison against base commit 9a36030.

♻️ This comment has been updated with latest results.

[pacmano1]

Tested with JSON, XML and HL7. Seems fixed. Excellent find whoever found it.

[tonygermano]

Tested with JSON, XML and HL7. Seems fixed. Excellent find whoever found it.

@pacmano1 Thank you for informing me of the issue 😛 The 4 datatypes affected would be HL7v2, delimited, edi, and NCPDP (all of the types that serialize from some other format to XML). JSON and XML itself should have been fine without this PR.

The class that is the subject of this PR was introduced in #223. It was being included in mirth-server.jar already, so everything was fine on the server side. Adding it to mirth-client-core.jar allows the client to use it, too.

[NicoPiel]

Superb find.

[mgaffigan]

This doesn't seem like a plugin - I suggest moving the class out of a subdirectory of plugins. Plugins have plugin manifests. The only other classes we ship from the plugins directories in core are immediate children of the plugins directory.

Suggest moving outside plugins namespace. If you wish for it to stay, make it an actual plugin.

[tonygermano]

This doesn't seem like a plugin - I suggest moving the class out of a subdirectory of plugins. Plugins have plugin manifests. The only other classes we ship from the plugins directories in core are immediate children of the plugins directory.

Suggest moving outside plugins namespace. If you wish for it to stay, make it an actual plugin.

@mgaffigan
The package name was created in #223, not this PR, which is only packaging the class for the client to be able to use it.

It is not a plugin, but an abstract class that functions like a plugin interface. The existing plugin interfaces live in the com.mirth.connect.plugins package, and that was the precedent I followed in the previous PR when I named it, changing mirth for OIE.

[mgaffigan]

@tonygermano

It is not a plugin, but an abstract class that functions like a plugin interface. The existing plugin interfaces live in the com.mirth.connect.plugins package, and that was the precedent I followed in the previous PR when I named it, changing mirth for OIE.

Then the include can presumably be narrowed to this class or directory specifically - the reference of the other plugin directory subtree match results in every plugin class getting shipped twice.