|
|
|
Re: [EMF] XSD enumerations end with "member0" when generated to Java [message #1404119 is a reply to message #1404116] |
Tue, 29 July 2014 17:42 |
Ed Merks Messages: 33137 Registered: July 2009 |
Senior Member |
|
|
Justin,
Yes, many of these industry standard schemas are a bit of a disaster
area. What you show below seems completely pointless, i.e., why not
define SomeRegex so that it includes the two possible enums then it
could just map to a String. Now you end up with something that might be
an enum value, or a string, and will need to do instance of checks and
only Object is a common type of the two. Horrible...
The approach I'd use would be to make a copy of the schema, annotate it
to produce what I wanted and generated from that annotated copy. I'm not
suggesting you structurally or semantically modify the schema; that's
obviously a no go.
On 29/07/2014 7:23 PM, Justin Field wrote:
> Ah thanks again for your help.
>
> That seems to be the exact problem. It seems that the new version of
> the schema changed how enumerations are defined from this:
>
> <xsd:simpleType name="TypeName">
> <xsd:restriction base="xsd:string">
> <xsd:enumeration value="val1">
> <xsd:enumeration value="val2">
> </xsd:restriction>
> </xsd:simpleType>
>
> to this:
> <simpleType name="TypeName">
> <union>
> <simpleType>
> <restriction base="string">
> <enumeration value="Val1"/>
> <enumeration value="Val2"/>
> </restriction>
> </simpleType>
> <simpleType>
> <restriction base="string">
> <pattern value="SomeRegex"/>
> </restriction>
> </simpleType>
> </union>
> </simpleType>
>
> Unfortunately, this schema is an industry standard so I can't really
> change it and I've probably got 100 or so generated classes that are
> showing this behavior.
> The bigger issue is that the generated classes are actually expecting
> the top level name in the classes that use the various enumerations,
> but are unable to find them as they are not being generated, only the
> <typeName>Member0 ones are. This means that wherever they are
> referenced in the thousands of other classes I have the getter/setters
> are expecting Objects.
> My initial thought is that I could write some kind of script that
> would change the names of the member0 classes and then iterate through
> the other classes and viewing the model annotation of each method to
> ensure that the return type is set correctly. It's a bit more custom
> of a workaround than I'd really like, but it seems doable enough.
>
> I must say that this EMF stuff is really cool though. Even with the
> issue I'm having it's saved me easily weeks of work if I were to do
> this manually, so my thanks go out to the development team.
>
> Thanks again for all of your help!
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03221 seconds