Bugzilla – Full Text Bug Listing
| Summary: | Validate EMF genmodel protocol at edit time, compile time and link time | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Ed Willink <ed> |
| Component: | Tools | Assignee: | Dave Steinberg <davidms> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | Ed.Merks |
| Version: | 2.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Ed Willink
Ed, I don't know how to turn your suggestion into an actual solution. I'll just add it to the list of error detection improvements we could work on if only we had time. *** This bug has been marked as a duplicate of 104727 *** This has a simple solution, so I've unduplicated.
How about YyyPackage containing a field such as
int YYY_GEN_MODEL_PROTOCOL_2_2_0M4 = ECORE_GEN_MODEL_PROTOCOL_2_2_0M4 + XXX_GEN_MODEL_PROTOCOL_2_2_0M4;
to indicate that YYY depends on ECORE and XXX compiled with a specific calling convention.
This
a) documents what exists and is required.
b) gives a not inappropriate compilation failure for a mismatch
c) gives a link failure for a mismatch (I would prefer only a warning here)
-- perhaps some game with soft references/reflection will do
provided "GEN_MODEL_PROTOCOL_2_2_0M4" is respelled whenever a breaking change is made.
Ed, I don't get it how this is supposed to work, i.e., how does this produce appropriate compilation or link failures? We certainly don't intend to change generation patterns on a regular basis. With the old patterns, if you change a base model and regenerate it, you'd need to regenerate derived models as well, e.g., to update eGet to pick up the new features. But with the new patterns and using the delegation to super approach, only a recompilation will be necessary (to recompute the feature IDs). So this problem of ensuring that derived models are regenerated to stay in synch with the base models has always existed. Probably when we move to Java 5.0 we'll be able to make use of annotations to assert that the base class is generated with a compatible pattern. In the meantime, we just don't have the resource to address an issue like this. *** This bug has been marked as a duplicate of 104727 *** Of course I meant:
int YYY_GEN_MODEL_PROTOCOL_2_2_0M4 = EcorePackage.ECORE_GEN_MODEL_PROTOCOL_2_2_0M4 +
XxxPackage.XXX_GEN_MODEL_PROTOCOL_2_2_0M4;
in YyyPackage, [and perhaps
int XXX_GEN_MODEL_PROTOCOL_2_2_0M4 = EcorePackage.ECORE_GEN_MODEL_PROTOCOL_2_2_0M4;
and in EcorePackage
int ECORE_GEN_MODEL_PROTOCOL_2_2_0M4 = 0; )
Each RHS term of the summation exists only if all sources were generated
at the same protocol level.
I use GEN_MODEL_PROTOCOL_2_2_0M4 and summation just by way of examples.
You might use _2_1 and logical ors to get a bit field perhaps...
This is not a duplicate bug, it's an enhancement request. We still don't see this as a significant problem that requires a solution, nor do we understand how the proposed solution is supposed to work. We may revisit this once we adopt Java 5. The basic problem is: If Model.ecore is distributed in genmodeled form by BasePlugin with method code generated using genmodel version X, we have what we might call Model/X code. If a DerivedPlugin extends Model.ecore, and uses genmodel version Y, the generation is based on what we might call Model/Y. Now if as occurred in my report, genmodel X and genmodel Y use different generation policies, then Model/X and Model/Y code are incompatible. This is not diagnosed, and proved to be very obscure. It must be diagnosed. My trick was to cause Model/X to appear as a distinct identifier so that a failure occurred when usage as Model/Y was attempted. This is closer to a bug than an enhancement request, since legitimate EMF usage gives a very bad user experience. Ed, Since we can't do this for the current release (it would require everyone to regenerate) and we didn't generate this information in old releases, there's really not much that can be done at this point. This type of change in pattern should not happen again, but if it does, we'll consider this type of approach. LATER/REMIND bugs are being automatically reopened as P5 because the LATER and REMIND resolutions are deprecated. Changing to WONTFIX because of the disappearance of the later/remind resolution. |