Frank, Thanks. I will leave SDOXSDEcoreBuilder and XSDHelperImpl alone. Fuhwei
Frank Budinsky <[EMAIL PROTECTED]> wrote: Fuhwei, I think it's reasonable for the generator to not let users generate the sdo model, since the generated code wouldn't work anyway. It's a very special case. It would be like someone trying to have their own version of java.lang.Class. If we want to regen sdoModel.xsd ourselves, we can do some under-the-covers things using EMF. Frank. Fuhwei Lwo wrote on 09/14/2006 05:21:52 PM: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
