|
Re: [EWL] EMF proxies resolving [message #1477457 is a reply to message #1477434] |
Mon, 17 November 2014 23:04 |
|
Hi Eric,
Model.resource should return the model's underlying EMF Resource. Off the top of my head, Model.allContents.exists(e|e.eIsProxy()) should return true if any proxies are left in the model.
Cheers,
Dimitris
|
|
|
|
|
Re: [EWL] EMF proxies resolving [message #1480832 is a reply to message #1478546] |
Thu, 20 November 2014 14:17 |
Eric Lépicier Messages: 25 Registered: October 2013 |
Junior Member |
|
|
Hi Dimitris,
operation resolveProxies(m) {
if (m.allContents.exists(e | e.eIsProxy())) {
var emfTool = new Native("org.eclipse.epsilon.emc.emf.tools.EmfTool");
emfTool.ecoreUtil.resolveAll(m.resource);
}
}
The code seems correct, even if I never go inside the if branch ... Nevertheless I removed the test to resolve systematically, but I still have my initial problems ...
I said I thought it was because of unresolved proxies, but I'm not so sure now !
The major problem, which I didn't explain yet, is that the references to the object which changed id are serialized with the old value.
Let's write an example with two objects A and B :
A.id = 1; B.refToA = A leads to <A id="1"/><B refToA = "#1"/> in the XMI file.
I set A.id to another value in my wizard. When the model is saved, I get <A id="2"/><B refToA = "#1"/>, with B.refToA unchanged and unresolvable ...
I tried to reproduce the error with a basic ecore metamodel, but it works like anybody should expect.
Do you have any idea why a metamodel implementation would serialize with this kind of error ?
It may not be an Epsilon problem, but I'd really like to be able to make it work and continue using Epsilon ...
Cheers,
--Eric
|
|
|
|
Re: [EWL] EMF proxies resolving [message #1494564 is a reply to message #1484472] |
Mon, 01 December 2014 15:28 |
Eric Lépicier Messages: 25 Registered: October 2013 |
Junior Member |
|
|
Hi Dimitris,
Unfortunately, as I said, when I try in a minimal example, it works well ... and I can't give you the whole thing due to confidentiality.
I think there's something special in the metamodel java implementation, in the API or in the serialization code. I have to speak with the authors ...
I also tried to modify the model with the Java generated API, using setId accessor, but it also failed.
Do you confirm it's the way to do it ?
I mean :
a.id = 3; // direct "data" access
a.setId(3); // Java API use
The first line doesn't call the Java API, true ?
Anther thing : the Java API seems to be the only way to access a derived feature, as it's only implemented there.
Does Epsilon try to call this API when one writes a "direct" access like e.derivedFeature ?
Cheers,
--Eric
|
|
|
Re: [EWL] EMF proxies resolving [message #1494922 is a reply to message #1494564] |
Mon, 01 December 2014 21:49 |
|
Hi Eric,
> Unfortunately, as I said, when I try in a minimal example, it works well ... and I can't give you the whole thing due to confidentiality.
No problem. If everything else fails I'm happy to sign an NDA (this is quite common).
> I also tried to modify the model with the Java generated API, using setId accessor, but it also failed.
a.id = 3 should delegate to a.setId(3) at runtime so the two statements should have the same effect.
> Anther thing : the Java API seems to be the only way to access a derived feature, as it's only implemented there.
> Does Epsilon try to call this API when one writes a "direct" access like e.derivedFeature ?
Yes.
Cheers,
Dimitris
|
|
|
Powered by
FUDForum. Page generated in 0.03562 seconds