|Re: AcceleoEvaluationException: Unresolved compilation error in generation module [message #1599182 is a reply to message #1580027]
||Tue, 03 February 2015 12:40
|| Pierre-Charles David
Registered: July 2009
Le 23/01/2015 09:35, Benoit Ries a écrit :|
> My issue is that I have this exception appearing sometimes (and most recently it is recurrent !) "AcceleoEvaluationException: Unresolved compilation error in generation module", see file attached for full exception log.
> My context: I specify an editor using the Sirius Specification Editor. For all complex expressions, I use Java classes and call them directly in Acceleo expressions using something like [thisEObject.myJavaMethod()/]. I have 4 java classes defined as Java Extensions in my viewpoint with around 20 methods per class (not sure this is relevant).
If your expressions are really just of the form
[thisEObject.myJavaMethod()/], you can bypass Acceleo completely and use
service:myJavaMethod instead. "service:" can't do much more than simply
invoking a Java method, but if that is all you need it is simpler and
faster than Acceleo.
Note that the Java class still has to be declared in the VSM, and it
must be deployed in the Eclipse instance. It can not simply be in the
workspace where the Sirius session is running.
> I have two questions:
> 1) So concretely, how do I debug these Acceleo compilation errors that seem to be caused by my Java extensions classes ?
There are some limitations in Acceleo in the context of Sirius, which
are documented here:
(just at the bottom): you can not use primitive types as arguments, and
you must return some value (the method can not return "void").
> Note that I don't see any compilation error in my java classes, but at runtime, the exception above is raised mentioning an unresolved compilation error in Acceleo.
> 2) What is the underlying process of compilation of java extensions used in Sirius Specification Editor ? any pointer or explanation would be appreciated.
Sirius does nothing very special here, at least as far as the "service:"
interpreter is concerned. It is not involved at all in the compilation
of the Java classes.
In your VSM you specify a fully-qualified Java class name. Sirius
assumes a compiled version of this is available from the deployed OSGi
bundle (Eclipse plug-in) which contains the VSM, and uses standard OSGi
to get an instance of it (see
for the implementation details). Note that the Java class must be in the
same bundle as the VSM; the code will not look inside the plug-in's
dependencies (for performance reasons). If your Java code lives
elsewhere, you must create a local wrapper which simply delegate the
implementation to the code in another plug-in.
The case of Acceleo is more complex. It used to be that Acceleo did some
magic tricks to deploy your Java service classes from you workspace
behind the scene, so that you did not have to launch a separate runtime
to test your modeler. However this relied on unsupported behavior of
Equinox/Eclipse, which has beed removed from recent versions of Eclipse,
so this "magic" behavior does not work anymore (see
Pierre-Charles David - Obeo
Need professional services for Sirius?
Pierre-Charles David - Obeo
Need training or professional services for Sirius?
Powered by FUDForum
. Page generated in 0.02170 seconds