(I started typing this reply when I read the pre-edited version of your message, so apologies if I’m repeating what you already know. Note that editing a talk post does not send email notification, so for people like me who primarily follow talk via email, we won’t see the changes.)
@mozzy, the issue we’re trying to address is that we prefer the changes we make to be backwards-compatible.
Since we’re moving the code from one module to another, that means that the fully-qualified Java package name for MetadataPackagesConfig has changed, so unless we do something about all existing usages of this feature will break when people upgrade the module.
For example the METS program has https://github.com/METS-Programme/openmrs-module-aijar/blob/cd17eefb617f30a89c51cb3c8ff136071855fab0/api/src/main/resources/packages.xml#L4
Our goal is that when they deploy a new version of the emrapi and metadatasharing modules, they do not have to make any changes to this XML file.
Xstream Aliasing may be the solution to this.
Specifically we want it to work so that if the file starts like this, it should work:
But going forward we should ask people to prefer this:
It’s okay if this also works, but let’s not advertise it, and let’s try to standardize on the package-free short version:
Xstream aliasing allows you to give an additional name (an alias) for a class. So it’s relevant because you can use this feature to tell the MetadataPackagesConfig class what other names/packages it should be recognized by.