Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 349431 - Generation code errors for enumeration types
Summary: Generation code errors for enumeration types
Status: RESOLVED INVALID
Alias: None
Product: EMF
Classification: Modeling
Component: Tools (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Ed Merks CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-15 09:18 EDT by dario CLA
Modified: 2011-06-15 09:51 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dario CLA 2011-06-15 09:18:16 EDT
Build Identifier: 20110301-1815

Assume that in the e-core model is defined an enumeration whose values are starting with digits. Such as like that:

      <eClassifiers xsi:type="ecore:EEnum" name="InputSignalCodeJ">
        <eLiterals name="3"/>
        <eLiterals name="2" value="1"/>
        <eLiterals name="4" value="2"/>
        <eLiterals name="1" value="3"/>
        <eLiterals name="5" value="4"/>
        <eLiterals name="6" value="5"/>
      </eClassifiers>

If you generate Java code with EMF, you will receive an error as the enumeration classes cannot have enumeration values starting with digits. 
The e-core model is generated starting from a UML produced by the ENTSO-E so we can't change that. There is some way to fix this problem?

Reproducible: Always

Steps to Reproduce:
1. Import the e-core model generated starting from the UML profile provided by ENTSO-E
2. Automatic generation of Java code by using EMF tools
3. Some errors are displayed for enumeration types
Comment 1 Ed Merks CLA 2011-06-15 09:51:33 EDT
The Ecore model won't validate either.  The XSD importer would add _ to the value to produce a valid name.  The UML importer should do that type of thing as well.  In other words, if you create Ecore directly, it's your problem to ensure you create well formed instances.  If the importer does it, the importer should ensure that it produces well formed instances.   I'm not sure if you're saying the UML importers not doing that. If so you should open the bug against UML2.