| Summary: | Generation code errors for enumeration types | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | dario <dario839.frazzetta> |
| Component: | Tools | Assignee: | Ed Merks <Ed.Merks> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
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. |
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