Community
Participate
Working Groups
There are situations where oclISKindOf fails using aql: syntax while it works correctly when using [/] syntax Step to reproduce: first workspace: - an ecore project - (and an xtext grammar for it) in the second runtime workspace: - a specification project - the same ecore project from first workspace is imported in this workspace, (this sometimes helps completion in sirius odesign) - some sample model (ideally using the xtext grammar) writing an expression in sirius such as aql: self.oclIsKindOf(logo::Forward) (in a conditional style for example) does not work but [self.oclIsKindOf(logo::Forward) /] do work correctly after some more investigations using the Sirius interpreter the expression aql: self.target.oclIsKindOf(logo::Forward) always returns false even if the selection is on the correct element with some more tests on expressions such as aql: if self.oclIsKindOf(logo::Forward) then self.oclAsType(logo::Forward).steps else null endif then the interpreter raises the following warning: several types are matching the EClassifier name: Forward, package name: logo note: closing the ecore project in the runtime workbench + restart, may solve the oclIsKindOf problem but in that case the completion does not work anymore in some part of the odesign: ex in the field Domain class* of a Node (tested on Sirius 6.1.1)
edit: the correct expression for the Sirius interpreter view that returns the warning is with some more tests on expressions such as aql: if self.target.oclIsKindOf(logo::Forward) then self.target.oclAsType(logo::Forward).steps else null endif
Hi, Have you correctly declared the metamodel from registry in the properties of the representation element in the odesign? If so does the problem still exists if you do not import the ecore project in the second workspace? On what kind of design element are you using aql: self.target.oclIsKindOf(logo::Forward) ?
If I do not import the ecore project in the second workspace, then the aql: expression seems to work correctly, but depending on how I reference the metamodel in the properties of the representation (platform/:plugin or platform:/resource) the completion in some other part of the odesign may not work anymore in the first or second workspace) > Have you correctly declared the metamodel from registry in the properties of the representation element in the odesign? yes, using "browse from workspace" (this is why I also imported the ecore project in the second workspace) If I use browse from registry, I do not need to import in the second workspace (thus making the odesign work correctly in the second workspace but not the first one if I use xmi files instead of xtext based files) as said, what is misleading here is that [/] and aql: syntax does not behave the same and crashes silently just because I imported a project in my workspace (my first (wrong) guess before further investigation was thas aql: was not supported yet in some odesign fields and that only [/] was working correctly ... :-( ) background: I'm currently writing a tutorial about writing DSLs involving xtext , sirius, and other technologies (GEMOC based debugger...). This kind of issues makes it difficult to have a smooth message because we have to change the way to reference the metamodel in the odesign depending on the order we write the editors (metamodel first,Sirius then xtext; or metamodel + xtext, then sirius)
Created attachment 277168 [details] project to reproduce Steps to reproduce: 1-Import all projects in runtime 2-open the diagram KO The man node should have the svg figure instead of the basic shape 3-In The design, change ManNode>conditionalStyle to [self.oclIsKindOf(basicfamily::Man)/] Then the figure are using the right svg. The metamodel is declared from workspace. From registry, it is working. It seems that AQL does not handle well the metamodel declared from workspace.
"If I use browse from registry, I do not need to import in the second workspace (thus making the odesign work correctly in the second workspace but not the first one if I use xmi files instead of xtext based files) " I don't really understand this problem, the scenario behind. Can you describe what is not working more precisely?
The scenario: Main goal: try to explain to language developers in which workspace they should do the modification on the odesign, how to correctly configure the workspaces, and how the correctly reference the metamodel in the odesign. If I want to workaround the oclIsKind of: - in the runtime workbench, remove metamodel declared from workspace and replace it by a metamodel declared from registry. Close or delete org.eclipse.sirius.sample.family from runtime workspace. Restart runtime eclipse. - in the runtime everything looks ok. so edition on the odesign should take place in this runtime workbench, however, If there are java services to write, the edition of the java files works best if done in the root eclipse workspace, so the org.eclipse.sirius.sample.basicfamily.starter.design should be opened there too. If the project is given to someone else she might be tempted to directly edit the odesign in the first eclipse (for example someone who learned to do all the work on the odesign in the first eclipse using "Create dynamic instance..." on the ecore file), but in this eclipse, the odesign doesn't work nicely (completion does not work since the registry doesn't know yet about the metamodel under development.) A workaround is possible for this later point by using dynamic EPackage registration, but I have no news about a possible integration in ecoretools (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=537295) anyway, this is mainly about finding workaround: a better solution would be to make sure aql correctly deal with metamodels from workspace in the second workbench ;-) note about the analysis of the bug: I'd bet that actually, in the second eclipse, aql see 2 versions of the sames classes (one from the workspace and one the registry) but does not prioritize them in a way that it can consider them equals or make sure to use only the worksapce one. Thus ending in a "Man class is not a Man class" and fails silently.
