Community
Participate
Working Groups
Steps to reproduce: 1- write a tool definition with a "For" expression which uses AQL and for which the return type is a collection of known types for instance with "container" being an EPackage use the expression: aql:container.eClassifiers 2- add a browse expression within the block of this for which uses a feature specific to the corresponding type (here EClassifier), for instance: aql:i.name When validating the .odesign an error "Feature not found in EClass EObject" is triggered whereas the expectation is that the tool is valid.
Created attachment 266093 [details] Archived VSM project to reproduce the error
Looking at the code AQLSiriusInterpreter.analyzeExpression(IInterpreterContext, String) actually ignore the type returned by AQL if it is not an EClassifierType and won't return the value at all, leading to a fall-back to EObject. Sirius has no notion of "multiple" or "collection" type in its typesystem and will unwrap the collection when using its result as the root of a new expression. It seems better to return the type information than hide which leads to a fall-back to EObject.
New Gerrit change created: https://git.eclipse.org/r/87940
Gerrit change https://git.eclipse.org/r/87940 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=7b0f6b1c494034864d2fde91add471808d08b706
Fixed by 7b0f6b1c494034864d2fde91add471808d08b706. The new test case for this scenario is added directly in the same commit.
Verified on Sirius 5.0M7.
Available in Sirius 5.0.0, see https://wiki.eclipse.org/Sirius/5.0.0 for details.