Home » Modeling » Epsilon » [Epsilon - EOL](Iterate over a resource without resolve the proxies)
|
Re: [Epsilon - EOL] [message #1775254 is a reply to message #1775218] |
Thu, 26 October 2017 21:26 |
|
Hi Antonio,
The code you have seems OK, but I think unchecking the "include external references" box in the EMF Model options should serve the same purpose, and you should be able to still do "X.all" as normal.
Could you try that out and let us know how it works for you?
Thanks!
Antonio
[Updated on: Thu, 26 October 2017 21:32] Report message to a moderator
|
|
|
Re: [Epsilon - EOL] [message #1775515 is a reply to message #1775254] |
Tue, 31 October 2017 09:19 |
Antonio Garmendia Messages: 93 Registered: May 2014 |
Member |
|
|
Hi Antonio,
Thanks for the reply!
I am executing EOL via standalone, but I have made a minimal example. I want to iterate only the objects inside the main resource, but I want that if any constraint has 'X.all', then eol resolve the proxies.
In the minimal example that I attached var contents = ecoreUtil.getAllContents(HControl1.resource, false); , contents is empty, because of this I suppose that eol is not compatible with TreeIterator, is that true?
Temporary solution:
I create a Java Method giving as a parameters Model.Resource and the name of the class. Basically the method, return a List<EObject> after having iterated all the objects of the model.
Cheers,
Antonio
[Updated on: Tue, 31 October 2017 09:22] Report message to a moderator
|
|
|
Re: [Epsilon - EOL] [message #1775524 is a reply to message #1775515] |
Tue, 31 October 2017 11:49 |
|
Unfortunately, I cannot run this example:
Internal error: java.lang.IllegalArgumentException: Could not locate a metamodel with the URI 'http://mondo.org/WT'. Please ensure that this metamodel has been registered with Epsilon.
Could you provide the matching metamodel?
I don't think Epsilon is incompatible with TreeIterator: we use it in some of our own code. There may be something else going on, but I need to get a minimal working example first ;-).
|
|
| |
Re: [Epsilon - EOL] [message #1775546 is a reply to message #1775526] |
Tue, 31 October 2017 21:09 |
|
Ah, didn't see it before I had to run off to a school meeting :-S.
The problem is that getAllContents(...) returns a TreeIterator, which (confusingly) is also a BasicEList of iterators :-). I believe Epsilon tries to treat it as a collection (as it is a BasicEList after all), rather than as a TreeIterator. This code works fine:
var emfTool : new Native("org.eclipse.epsilon.emc.emf.tools.EmfTool");
var ecoreUtil = emfTool.ecoreUtil;
var contents = ecoreUtil.getAllContents(HControl1.resource, false);
while (contents.hasNext()) {
contents.next().println();
}
It produces this output:
Subsystem [name=HControl1, ]
Subsystem [name=HControl2, ]
ControlSubsystem [name=H2Control1, ]
StateMachine [name=null, isPublic=true]
InitialState [name=null, description=null, ]
SimpleState [name=null, description=null, ]
ControlSubsystem [name=H2Control2, ]
ControlSubsystem [name=H2Control3, ]
ControlSubsystem [name=H2Control4, ]
ControlSubsystem [name=H2Control5, ]
StateMachine [name=a, isPublic=true]
InitialState [name=null, description=null, ]
SimpleState [name=null, description=null, ]
Architecture [name=H1Arquitecture, ]
Component [label=null]
ControlSubsystem [name=HControlDefinition, ]
ControlSubsystem [name=H2, ]
ControlSubsystem [name=H3, ]
ControlSubsystem [name=H4, ]
ControlSubsystem [name=new_file, ]
Is that the behaviour you wanted?
[Updated on: Tue, 31 October 2017 21:11] Report message to a moderator
|
|
| |
Re: [Epsilon - EOL] [message #1775637 is a reply to message #1775627] |
Thu, 02 November 2017 11:53 |
|
Hi Antonio,
This is interesting - apparently, during loading Epsilon inadvertently resolves the proxies even though it is not meant to do so. I will file this as a bug on follow up on it with Dimitris - sounds like our use of eAdapters to track containment change might be a problem.
Kind regards,
Antonio
|
|
| | |
Goto Forum:
Current Time: Thu Sep 26 08:12:36 GMT 2024
Powered by FUDForum. Page generated in 0.04286 seconds
|