Our codegen requires users to manually instantiate the builder for union types, which parses a string. RFC6020, specifies the following:

   When a string representing a union data type is validated, the string
   is validated against each member type, in the order they are
   specified in the "type" statement, until a match is found.

This removes enough ambiguity, such that we can auto-generate a proper builder. Generate the builder (still in src/main, as we need to maintain compatibility).

Unfortunately this is not enough to implement the desired functionality: a union member can be either an instance-identifier, an identityref or a leafref (to one of those two types). Reconstructing those two types, even if we solve the ugly String format part (which has to end up not conflicting with previous listed members), requires loading classes.

This cannot be achieved in a general way when we are in a JPMS/OSGi environment when the code implementing this functionality resides in the module/bundle defining the union, as it simply does not have access to the totality of classes. The only way to make that work is to have a runtime component which integrates with the environment in a manner similar to binding-dom-codec – e.g. it has proper access to BindingRuntimeContext and can make decisions on that level.

So rather than attempting to fix this wart, let's remove the union builders altogether: they are not referenced from generated code at all and therefore are only utilities for code. Utilities are best hand-crafted for a particular use case without a straight-jacket and in the appropriate component, with proper visibility and implementation constraints.