| [EMF] XSD enumerations end with "member0" when generated to Java [message #1403985] |
Mon, 28 July 2014 19:09  |
Eclipse User |
|
|
|
Hi all,
I'm rather new to all of this EMF stuff and have a very large XSD schema I'm trying to convert to EMF objects.
I'm having an issue where all of my enumerations are generated to java files that read <EnumName>Member0.java instead of just the expected <EnumName>.java.
It looks similar to this issue from 2004 I found here http://www.eclipse.org/forums/index.php?t=msg&&th=126408&goto=388217.
Has anyone else encountered this issue and know of a workaround? Am I somehow using an ancient version of EMF? I'm running Eclipse Luna, but I was having problems getting the versions to generate models from XSD's by default so it's quite possible I downloaded an old plugin or something by mistake...
Thank you for your help!
|
|
|
|
|
| Re: [EMF] XSD enumerations end with &quot;member0&quot; when generated to Java [message #1404119 is a reply to message #1404116] |
Tue, 29 July 2014 13:42  |
| Eclipse User |
|
|
|
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!
>
|
|
|
Powered by
FUDForum. Page generated in 0.03614 seconds
Home