Community
Participate
Working Groups
Build Identifier: 20090920-1017 When trying to write checks for a model and trigger them from the Generic EMF Form Editor everything is working fine as long as the check file does not contain a rule using a call to a Java method. If it does the message "An Error occured during checking: java.util.NoSuchElementException" appears in the title bar when pressing the Check button in the Generic EMF Form Editor or saving the file. Additional information: http://www.eclipse.org/forums/index.php?t=msg&th=169086&start=0& Reproducible: Always Steps to Reproduce: 1. Take any metamodel (e.g. metamodel.ecore, root element MainObject) 2. Create a corresponding Check file (metamodel/Checks.chk) import metamodel; extension extend::metamodel; context MainObject ERROR "Error": this.test(); 3. Create Xtend file containing function (extend/metamodel.ext) import metamodel; Boolean test(MainObject object): JAVA javacode.Library.test(metamodel.MainObject) 4. Create Java file containing function (javacode/Library.java) package javacode; import metamodel.MainObject; public class Library { public static boolean test(MainObject object) { return true; } } 5. Trigger check in Generic EMF Form Editor (press check button or save modified file)
The same problem exists with ItemLabelProvider.ext where implementing label() as static Java method does not work correctly, either. The steps to reproduce are equivalent to the case described above (provide a Java implementation for label(), e.g. adapting the STR from #322902). Digging a bit into the code I could figure out that in that case loading the Java class providing the static method fails: In org.eclipse.internal.xtend.xtend.ast.JavaExtensionStatement.evaluateInternal(), getJavaMethod() yields null. I suspect that this is due to the ExecutionContext object, but I am no expert of xtend. I verified that this code path is taken for both Checks.chk as well as ItemLabelProvider.ext. I could successfully run the same Java method from an xtend script via a MWE workflow, but here the stack is quite different and org.eclipse.xtend.expression.ExpressionFacade seems to do the right thing (or is provided with a correct execution context). Any thoughts or hints who to debug this further?
Won't work with Java extensions.