eclipse-ocl-bot
commented
2 months ago By Ed Willink on Mar 17, 2020 06:32
(In reply to Ed Willink from comment #0)
the autogeneration requires significant manual fixup.
This proves to be rather easy.
a) GenModel supports the "internal.{0}" pattern that gives the correct name suffix for the implementation package.
b) "@generated not" for a *Impl class allows a non-standard class declaration without inhibiting auto-generated content.
A little catching up in Values.ecore for e.g. MapValue is required and a couple of declarations needrefining to make NullValue / InvalidValue happy.
The model root requires a bit more @generated not than is desirable, but EMF expects a common EObject-like root. Some values classes have real roots such as Number or Exception.
No breakage occurs in QVTd which has four (two distinct styles) of questionable internal.values.ValueIml/SetValueImpl import.
The *Impl/java is substantially @Generated NOT, but now that the interfaces/classes and hierarchy are auto-generated in a regular fashion, declaration can be moved to the model as required.
A liitle work on API filters is needed.
| --- | --- | | Bugzilla Link | 561146 | | Status | NEW | | Importance | P3 normal | | Reported | Mar 16, 2020 04:54 EDT | | Modified | Mar 19, 2020 11:34 EDT | | Blocks | 520440 | | See also | 383983, 561265 | | Reporter | Ed Willink |
Description
Bug 383983 eliminated the anomally that Values classes were 100% manual by providing a Values.ecore/Values.genmodel. But API compatibility mandated that the autogeneration requires significant manual fixup.
It would be really good to avoid this manual fixup. Maybe after renaming the *Impl packaging it could work.
(Bug 520440 requires some new SymbolicValues whose ongoing manual coding is undesitable.)