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 c
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
Fuhwei,
I've been encountering a similar problem using dynamic data objects, and
although I haven't yet fully absorbed the detail of your problem in the
generated space I thought I'd sharethe solution to my problem, as I think
it may have a bearing on yours.
My problem was that in order to g
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 SDOXSDEcoreB
