I think we may have a scenario that Java SDO codegen would fail to generate
Java codes from XSD. The scenario is when I tried to run codegen tool on
sdoModel.xsd with target namespace, commonj.sdo, the codegen would perform
no-op. The reason is the fix for TUSCANY-676 has forced SDOXSDEcoreBuilder to
load types of the commonj.sdo namespace so when XSD2JavaGenerator.java invokes
XSDHelper.define() method to load sdoModel.xsd again for codegen, define()
method won't register commonj.sdo namespace because it already exists.
After looking into XSD2JavaGenerator.java, I think what it needs is to have
a clean/empty registry without any SDO types registered. However, the current
implementation is to use both EMF (for codegen APIs) and SDO (for utilizing
define() method) APIs but SDO didn't provide a way of not registering its
default model, sdoModel.xsd. If we go down this road, we need to fix
SDOXSDEcoreBuilder.java to create a constructor without init sdoModel.
However, this is not enough. XSD2JavaGenerator needs to access
extendedMetaData in XSDHelperImpl to get to the registry so XSDHelperImpl
needs to expose its private member, extendedMetaData. I don't think this is a
good idea.
Another alternative is to add a new argument to the XSDHelperImpl
constructor to indicate whether the default SDO model should be init so
XSD2JavaGenerator can create an instance of XSDHelperImpl without initializing
the SDO model.
Another alternative is XSD2JavaGenerator basically doesn't use XSDHelper or
other SDO APIs. Use EMF APIs instead. This approach may duplicate some codes
but we don't worry about bridging two sets of API.
Let me know what you think so I can prototype the solution. Thanks.
Fuhwei
