Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Xcore workaround for bug 89325???(Trying to figure out how to get around the subject bug when my model is in Xcore)
Xcore workaround for bug 89325??? [message #1695987] Wed, 20 May 2015 22:49 Go to next message
Erick Hagstrom is currently offline Erick HagstromFriend
Messages: 108
Registered: April 2014
Location: USA
Senior Member
Hey folks! *waves at Ed Merks*

One of my team members stumbled across bug number 89325 after wresting with the issue expressed therein. We see the workaround recommended for people who are using straight Ecore and are willing to modify their generated code. We are using Xcore and would really prefer to leave the generated code in the src-gen folder and treat it like, well, generated code. (Yes, we understand that there are configuration management wrinkles here, and we've made the informed choice that this is how we'd like to do things.)

So here we are in Xcore with noncontainment unidirectional references to EObjects that are contained elsewhere. Our use case looks very much like the popular method argument use case that seems to be accepted as legitimate. And we find ourselves stuck.

Problem #1: how do we even specify non-unique on the reference? There's a "unique" keyword, but the unique property is true whether "unique" is present or absent. We've tried doing a @Ecore annotation on the reference, but all we've found is multiple ways that doesn't work. So it doesn't seem like it's even possible to specify a non-unique refers in Xcore.

Problem #2: bug 89325 is still floating around. What's the best way to work around it now? Do we absolutely need to override the EObjectResolvingEList.isUnique() method in the generated code? Cuz, though we'd rather not, if that's the only way, well, "where there is clarity there is no choice, and where there is choice there is misery", eh?
Re: Xcore workaround for bug 89325??? [message #1696007 is a reply to message #1695987] Thu, 21 May 2015 06:57 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30351
Registered: July 2009
Senior Member
Erick,

Comments below.


On 21/05/2015 12:49 AM, Erick Hagstrom wrote:
> Hey folks! *waves at Ed Merks*
>
> One of my team members stumbled across bug number 89325 after wresting
> with the issue expressed therein.
That horrible old thing...
> We see the workaround recommended for people who are using straight
> Ecore and are willing to modify their generated code. We are using
> Xcore and would really prefer to leave the generated code in the
> src-gen folder and treat it like, well, generated code. (Yes, we
> understand that there are configuration management wrinkles here, and
> we've made the informed choice that this is how we'd like to do things.)
>
> So here we are in Xcore with noncontainment unidirectional references
> to EObjects that are contained elsewhere. Our use case looks very much
> like the popular method argument use case that seems to be accepted as
> legitimate. And we find ourselves stuck.
:-(
>
> Problem #1: how do we even specify non-unique on the reference?
> There's a "unique" keyword, but the unique property is true whether
> "unique" is present or absent.
I see what you mean. I suppose that's semi-intentional, but isn't
really right given the grammar...
> We've tried doing a @Ecore annotation on the reference, but all we've
> found is multiple ways that doesn't work. So it doesn't seem like it's
> even possible to specify a non-unique refers in Xcore.
So you tried @Ecore(^unique="false") and noticed it threw exceptions
(trying to assign the string value to the boolean feature). That
should really be fixed. Please open a bugzilla if that helps...
>
> Problem #2: bug 89325 is still floating around. What's the best way to
> work around it now? Do we absolutely need to override the
> EObjectResolvingEList.isUnique() method in the generated code?
Yes, sorry...
> Cuz, though we'd rather not, if that's the only way, well, "where
> there is clarity there is no choice, and where there is choice there
> is misery", eh?
Indeed.
Re: Xcore workaround for bug 89325??? [message #1696067 is a reply to message #1696007] Thu, 21 May 2015 13:26 Go to previous message
Erick Hagstrom is currently offline Erick HagstromFriend
Messages: 108
Registered: April 2014
Location: USA
Senior Member
Thanks, Ed. Opening the bugzilla on @Ecore(^unique="false"). (And yes, that's what we thought it ought to be, and yes, that's what happened when we tried it. The new bug is https://bugs.eclipse.org/bugs/show_bug.cgi?id=467855

We managed to find a workaround for bug 89325 itself.

First, we wrote an extension of EObjectResolvingEList that returned false in isUnique(). Then, wherever we needed it, we created an attribute of that List type and a getWhatever() method that does exactly what the generated code would otherwise do: create the List if it doesn't exist, then return it.

So now we have choice, and we're miserable. Wink
Previous Topic:EMF.Edit and Databinding
Next Topic:[CDO] How do Passive updates work ?
Goto Forum:
  


Current Time: Sun Aug 18 21:22:10 GMT 2019

Powered by FUDForum. Page generated in 0.02297 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top