Home » Modeling » M2T (model-to-text transformation) » [xPand] Access OCL derivation during generation
| [xPand] Access OCL derivation during generation [message #854755] |
Tue, 24 April 2012 08:05  |
 Christopher Gerking
Messages: 115
Registered: April 2011 |
Senior Member |
|
|
One of the classes in my ecore file has a derived attribute of type EString. Cardinality is 0..1, implementation is OCL-based.
When creating a dynamic instance of the meta-model, the derivation works fine. However, if I run the xPand generator from the development workspace, the derivation does not work. If I use the EmfRegistryMetaModel, the result of the derivation is just null. The same happens if I use EmfMetaModel and refer to the ecore via metaModelFile. If I refer to the meta model via metaModelPackage, I get a NPE from the model code (EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet).
How can I enable the OCL derivation during code generation?
[Updated on: Tue, 24 April 2012 08:06] Report message to a moderator |
|
|
| Re: [xPand] Access OCL derivation during generation [message #855107 is a reply to message #854755] |
Tue, 24 April 2012 14:24  |
Ed Willink
Messages: 7635
Registered: July 2009 |
Senior Member |
|
|
Hi
Mixing OCL and Xpand is somewhat unusual but it should just work in so
far as the Xpand code generation should use the normal EMF getXXX,
eGet(XXX) protocols and so should be unaware that the implementation
uses EMF delegation to an OCL interpreter.
However, you are almost certainly the first person to try this, so I
suggest producing a small repro and filing a bug with the full NPE stack
trace.
[Juno will provide an option for OCL to Java generation which may
eliminate a complexity that is currently failing.]
Regards
Ed Willink
On 24/04/2012 09:05, Missing name Mising name wrote:
> One of the classes in my ecore file has a derived attribute of type
> EString. Cardinality is 0..1, implementation is OCL-based.
>
> When creating a dynamic instance of the meta-model, the derivation
> works fine. However, if I run the xPand generator from the development
> workspace, the derivation does not work. If I use the
> EmfRegistryMetaModel, the result of the derivation is just null. The
> same happens if I use EmfMetaModel and refer to the ecore via
> metaModelFile. If I refer to the meta model via metaModelPackage, I
> get a NPE from the model code
> (EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet).
>
> How can I enable the OCL derivation during code generation?
>
>
|
|
| | |
| Re: [xPand] Access OCL derivation during generation [message #857263 is a reply to message #856148] |
Thu, 26 April 2012 11:58 |
Christopher Gerking
Messages: 115
Registered: April 2011 |
Senior Member |
|
|
I am executing the workflow from eclipse, however, not from a runtime instance. Hence, the model code as well as the workflow are located within workspace projects.
This is the trace if it looks like when I'm using EmfMetaModel with metaModelPackage.
As I said, in all other cases, there is no trace since the derivation result is just null.
The NPE appears since for the call to EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet, the settings argument (class DynamicValueHolder) is null.
java.lang.NullPointerException
at org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateSingleData.dynamicGet(EStructuralFeatureImpl.java:1986)
at de.uni_paderborn.fujaba.muml.verification.uppaal.impl.EdgeImpl.getSynchronizationLabel(EdgeImpl.java:273)
at de.uni_paderborn.fujaba.muml.verification.uppaal.impl.EdgeImpl.eGet(EdgeImpl.java:570)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1021)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1013)
at org.eclipse.emf.ecore.impl.BasicEObjectImpl.eGet(BasicEObjectImpl.java:1008)
at org.eclipse.xtend.typesystem.emf.EClassType$1.get(EClassType.java:71)
at org.eclipse.internal.xtend.expression.ast.FeatureCall.evaluateInternal(FeatureCall.java:121)
at org.eclipse.internal.xtend.expression.ast.Expression.evaluate(Expression.java:50)
at org.eclipse.internal.xtend.expression.ast.OperationCall.evaluateInternal(OperationCall.java:60)
at org.eclipse.internal.xtend.expression.ast.Expression.evaluate(Expression.java:50)
at org.eclipse.internal.xpand2.ast.IfStatement.evaluateInternal(IfStatement.java:86)
at org.eclipse.internal.xpand2.ast.Statement.evaluate(Statement.java:41)
at org.eclipse.internal.xpand2.ast.AbstractDefinition.evaluate(AbstractDefinition.java:180)
at org.eclipse.internal.xpand2.ast.ExpandStatement.invokeDefinition(ExpandStatement.java:246)
at org.eclipse.internal.xpand2.ast.ExpandStatement.evaluateInternal(ExpandStatement.java:191)
at org.eclipse.internal.xpand2.ast.Statement.evaluate(Statement.java:41)
at org.eclipse.internal.xpand2.ast.AbstractDefinition.evaluate(AbstractDefinition.java:180)
at org.eclipse.internal.xpand2.ast.ExpandStatement.invokeDefinition(ExpandStatement.java:246)
at org.eclipse.internal.xpand2.ast.ExpandStatement.evaluateInternal(ExpandStatement.java:191)
at org.eclipse.internal.xpand2.ast.Statement.evaluate(Statement.java:41)
at org.eclipse.internal.xpand2.ast.FileStatement.evaluateInternal(FileStatement.java:86)
at org.eclipse.internal.xpand2.ast.Statement.evaluate(Statement.java:41)
at org.eclipse.internal.xpand2.ast.AbstractDefinition.evaluate(AbstractDefinition.java:180)
at org.eclipse.internal.xpand2.ast.ExpandStatement.invokeDefinition(ExpandStatement.java:246)
at org.eclipse.internal.xpand2.ast.ExpandStatement.evaluateInternal(ExpandStatement.java:226)
at org.eclipse.internal.xpand2.ast.Statement.evaluate(Statement.java:41)
at org.eclipse.xpand2.Generator.invokeInternal2(Generator.java:333)
at org.eclipse.xtend.expression.AbstractExpressionsUsingWorkflowComponent.invokeInternal(AbstractExpressionsUsingWorkflowComponent.java:239)
at org.eclipse.emf.mwe.core.lib.AbstractWorkflowComponent.invoke(AbstractWorkflowComponent.java:126)
at org.eclipse.emf.mwe.core.container.CompositeComponent.internalInvoke(CompositeComponent.java:104)
at org.eclipse.emf.mwe.core.container.CompositeComponent.invoke(CompositeComponent.java:89)
at org.eclipse.emf.mwe.core.WorkflowEngine.executeWorkflow(WorkflowEngine.java:174)
at org.eclipse.emf.mwe.core.WorkflowEngine.run(WorkflowEngine.java:53)
at org.eclipse.emf.mwe.core.WorkflowRunner.doRun(WorkflowRunner.java:174)
at org.eclipse.emf.mwe.core.WorkflowRunner.main(WorkflowRunner.java:69) [Updated on: Thu, 26 April 2012 12:39] Report message to a moderator |
|
| | | |
| Re: [xPand] Access OCL derivation during generation [message #874709 is a reply to message #857444] |
Mon, 21 May 2012 12:04 |
Christopher Gerking
Messages: 115
Registered: April 2011 |
Senior Member |
|
|
Hi,
in the meantime, my code generation works fine executing the suggested OCL standalone configuration, but only on dynamic instances.
Now, I am trying the execute the generation on a model resulting from a GMF editor. The result is the same NPE as before.
This is the code that is executed for the OCL standalone setup:
OCL.initialize(null);
String oclDelegateURI = OCLDelegateDomain.OCL_DELEGATE_URI;
EOperation.Internal.InvocationDelegate.Factory.Registry.INSTANCE.put(oclDelegateURI, new OCLInvocationDelegateFactory.Global());
EStructuralFeature.Internal.SettingDelegate.Factory.Registry.INSTANCE.put(oclDelegateURI, new OCLSettingDelegateFactory.Global());
EValidator.ValidationDelegate.Registry.INSTANCE.put(oclDelegateURI, new OCLValidationDelegateFactory.Global());
QueryDelegate.Factory.Registry.INSTANCE.put(oclDelegateURI, new OCLQueryDelegateFactory.Global());
Is there something missing to make it work on non-dynamic model instances?
[Updated on: Mon, 21 May 2012 12:58] Report message to a moderator |
|
|
| Re: [xPand] Access OCL derivation during generation [message #874746 is a reply to message #874709] |
Mon, 21 May 2012 13:28 |
Ed Willink
Messages: 7635
Registered: July 2009 |
Senior Member |
|
|
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi<br>
<br>
Have you looked at the OCL Documentation?<br>
<br>
Regards<br>
<br>
Ed Willink<br>
<div class="titlepage">
<div>
<div>
<h3 class="title"><a name="Ecore"></a>Ecore</h3>
</div>
</div>
</div>
<p>For the Ecore metamodel, the required registrations should be
provided by invoking <code class="code">org.eclipse.ocl.ecore.OCL.initialize(ResourceSet)</code>.
</p>
<p>This may be invoked with a null argument to install the
registrations in the global EPackage.Registry. This is not
normally recommended, but since this is for your application, the
integrity of the global registry is your responsibility.</p>
<p>It is normally recommended to install the registrations solely
for use in your own ResourceSet and to pass that to the initialize
routine.</p>
<p>This initialization ensures that *.ecore is understood.</p>
<p>If you want to use EMF delegates to dispatch OCL, the required
registrations may be provided by <code class="code">org.eclipse.ocl.ecore.delegate.DelegateDomain.initialize(ResourceSet)</code>.
</p>
<p>This may be invoked with a null argument to install the
registrations in the global EPackage.Registry rather than a
specified local registry.<br>
</p>
<p><br>
</p>
<br>
<br>
On 21/05/2012 13:04, Christopher G. wrote:
<blockquote cite="mid:jpdb07$i8p$1@xxxxxxxxe.org" type="cite">Hi,
<br>
<br>
in the meantime, my code generation works fine executing the
suggested OCL standalone configuration, but only on dynamic
instances.
<br>
<br>
Now, I am trying the execute the generation on a model resulting
from a GMF editor. The result is the same NPE as before.
<br>
<br>
This is the code that is executed for the OCL standalone setup:
<br>
<br>
<br>
OCL.initialize(null);
<br>
<br>
String oclDelegateURI = OCLDelegateDomain.OCL_DELEGATE_URI;
<br>
<br>
EOperation.Internal.InvocationDelegate.Factory.Registry.INSTANCE.put(oclDelegateURI,
new OCLInvocationDelegateFactory.Global());
<br>
EStructuralFeature.Internal.SettingDelegate.Factory.Registry.INSTANCE.put(oclDelegateURI,
new OCLSettingDelegateFactory.Global());
<br>
EValidator.ValidationDelegate.Registry.INSTANCE.put(oclDelegateURI,
new OCLValidationDelegateFactory.Global());
<br>
QueryDelegate.Factory.Registry.INSTANCE.put(oclDelegateURI, new
OCLQueryDelegateFactory.Global());
<br>
<br>
<br>
Is there something missing to make it work on non-dynamic model
instances?
<br>
</blockquote>
<br>
</body>
</html>
|
|
| | | | | | | | |
| Re: [xPand] Access OCL derivation during generation [message #880056 is a reply to message #880004] |
Fri, 01 June 2012 10:44 |
|
There is no dedicated OCL support in Xpand now. Christopher tries to write a standalone setup component that must be integrated in a workflow.
BTW: It is not necessary to derive it from AbstractWorkflowComponent, just a simple bean that does the initialization code in its constructor, or when setting properties.
public class OCLStandaloneConfiguration {
public OCLStandaloneConfiguration () {
OCL.initialize(null);
OCLDelegateDomain.initialize(null);
}
}
<!-- configure OCL for standalone execution -->
<bean class='setup.OCLStandaloneConfiguration'/>
For easier testing it would be better if you include a model and OCL execution in the .generator project, so that the project is self contained.
Need professional support for Xtext, EMF, Eclipse IDE?
Go to: http://devhub.karakun.com
Twitter : @kthoms
Blog : www.karsten-thoms.de
|
|
| |
Goto Forum:
Current Time: Sat Dec 02 02:40:46 GMT 2023
Powered by FUDForum. Page generated in 0.03002 seconds |
] 
Search
Help
Register
Login
Home
