Bugzilla – Full Text Bug Listing
| Summary: | GenModel Class/Interface Name Pattern should also allow to remove part of the original element name | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Mirko Raner <mirko> |
| Component: | Tools | Assignee: | Dave Steinberg <davidms> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | Ed.Merks |
| Version: | 2.6.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Use an ecore:type annotation to produce the Ecore names you really want. That makes particularly good sense for anonymous types, which is the only case were a "type" suffix is added. That seems better than having Ecore names you don't want and then to mess with the generator to produce nicer ones. Hm, I'm not really happy with manually editing the ECore file. As I mentioned earlier, the ECore file itself is generated from an XML schema (and that schema unfortunately contains the "Type" suffix for some element types). Also, the original schema changes every so often and I would like to use a build procedure where I can quickly regenerate the ECore from the schema and the GenModel from the ECore. Neither the ECore not the GenModel would be checked into source control. I see how I can put ecore:type annotations into the ECore file, but every time the original schema changes I either have to regenerate the ECore file and manually re-add all the annotations, or (if the changes are small enough) merge in the changes from the new generated file. Either way, it's not exactly the process I have in mind when using model-driven development. Is there some other option to address this problem? I probably should clarify that I cannot change the original XML schema either, because that schema is not maintained by us. I'd rather support https://bugs.eclipse.org/bugs/show_bug.cgi?id=197943 than further complicate the generator. In any case, you can always modify a copy of the schema and when the "real" schema changes, you could merge your changes back into it. You'd need to regenerate anyway when the "real" schema changes. Bug 197943 sounds like a good compromise to me. Making copies of things and then merging back changes when the original has changed doesn't typically work very well in fast-moving environments. Ideally, I am looking for a process where no generated or derived artifacts are ever checked into source control. Sure, there are certain breaking changes in an XML schema that would break clients of the generated API (for example, a type being removed that is currently used by an API client). But aside from that there should be no manual merging work when there is an addition or minor change to the original XML schema. I voted for bug 197943, and I hope we can implement this feature for the Indigo release. The idea behind that bug is to keep the annotations external so that minor changes wouldn't break the association between the annotation and what's being annotated. Of course you'd need to maintain your annotations. You could always write a script that massages the Ecore to produce the names you want, but then you'd have to maintain that script. |
By using the "Class Name Pattern" and "Interface Name Pattern" properties, I can tell the EMF Model Generator to name interfaces as "I{0}" or classes as "{0}Impl", for example. Currently, the processing performed in GenImplBase is a simple Java MessageFormat, and the original element name will always be fully included in the resulting class or interface name. There is currently no way to only have a part of the original element name be used as basis for the generated names. For example, my ECore file is generated from an XSD schema in which some of the complex data types have a "Type" suffix (e.g., MoneyType instead of just Money). I would like to exclude the Type suffix from the class and interface names, so that the element MoneyType would translate into the interface name Money and the implementation class name MoneyImpl. One way to achieve this, would be by allowing regex Patterns in addition to the regular MessageFormat processing. If the formatting parameter is anything other than {0}, then the content between the braces would be interpreted as a regex Pattern that must define a capturing group. The capturing group's value would serve as the parameter for the MessageFormat. If there was no match, the original name would be used. For example, to achieve what I was describing above, one would use: Interface Name Pattern: {(.+)Type} Class Name Pattern: {(.+)Type}Impl This is just a possible idea for implementing this functionality, and certainly not the only possibility. We might find a more elegant approach if we think about this a little more. I'm happy to provide a patch once we have made a decision how to approach this.