Eclipse Community Forums: EMF » [EMF] XSD enumerations end with "member0" when generated to Java

Help

Home

Home » Modeling » EMF » [EMF] XSD enumerations end with "member0" when generated to Java

Show: Today's Messages :: Show Polls :: Message Navigator

[EMF] XSD enumerations end with "member0" when generated to Java [message #1403985]

Mon, 28 July 2014 23:09

Justin Field

Messages: 7
Registered: July 2014

Junior Member

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!

Report message to a moderator

Re: [EMF] XSD enumerations end with "member0" when generated to Java [message #1403996 is a reply to message #1403985]

Tue, 29 July 2014 04:26

Ed Merks

Messages: 30553
Registered: July 2009

Senior Member

Justin,

Comments below.

On 29/07/2014 1:17 AM, Justin Field wrote:
> 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.
So it sounds like anonymous simple types are involved. The best way to
get the name you want for those is to use an ecore:name annotation in
the schema.
>
> 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?
Any time you have an anonymous type, EMF is forced to create a name for
one. You might not like that name, in which case you need to choose one
explicitly.
> 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!

Report message to a moderator

Re: [EMF] XSD enumerations end with "member0" when generated to Java [message #1404116 is a reply to message #1403996]

Tue, 29 July 2014 17:23

Justin Field

Messages: 7
Registered: July 2014

Junior Member

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!

Report message to a moderator

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 17:42

Ed Merks

Messages: 30553
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!
>

Report message to a moderator

Previous Topic:	How to debug a XMI load error?
Next Topic:	java.lang.ExceptionInInitializerError

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Oct 22 22:42:53 GMT 2019

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter