Community
Participate
Working Groups
Build Identifier: Eike Stepper started a newsgroup thread about this topic on 10/17/2010 and forgot to submit a bugzilla. For EENums we could assume, that 99.9% of the time no one would specialize the code of the generated factory. Reproducible: Always
Want to include a link to that thread? We could assume that and be wrong only .1% of the time as opposed to assuming nothing but overlooking potential/likely problems that aren't discovered until later. It's a trade-off...
There we go: http://www.eclipse.org/forums/index.php?t=tree&th=198598&S=be02a6e8c0f3f310f9e08de483893912
This bug caused a very mysterious NPE in CDO and we spent a lot of time trying to find the cause. Only after hiring Eike the CDO master we were pointed to this discrepancy in our model. We were quite surprised that this mismatch was not detected by the ECore validator of model generator. We would appreciate if this could be fixed to spare future users the painful search for mystery bugs.
Hello, I recently had to spend a lot of time because of this issue myself. In my case Eike Stepper was kind enough to send me looking in the right direction. He believes that this was the issue I was running into. I had an EAttribute that was using an EENum which had no default literal value. The following Eclipse forum thread link will explain what went on. http://www.eclipse.org/forums/index.php/t/441349/ I'm just hoping this can be fixed so future users won't be plagued with this. Thanks Eike!
I've changed the logic for special case handling of literals for enums (as well as for types with conversion delegates). http://git.eclipse.org/c/emf/org.eclipse.emf.git/commit/?id=09bf73b41dbfdfc9978834a6943ea2f314a11879
You're the greatest ;-)
The changes are available in Kepler.