Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4155
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 #856112 is a reply to message #855107] Wed, 25 April 2012 11:33 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
Member
Is it actually that unusual? I mean, my meta-model serves as the basis for different tasks (visual modeling, code generation etc.) Isn't it a good idea to implement derivations only once as part of the meta-model itself using OCL? Otherwise I have to re-implement every derivation using xTend.

BTW: could the error be caused by the fact that I use a dynamic instance XMI-file for the code generation?
Re: [xPand] Access OCL derivation during generation [message #856148 is a reply to message #854755] Wed, 25 April 2012 12:08 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4155
Registered: July 2009
Senior Member
Hi

I obviously think that using OCL is a good idea. I was just observing
that Eclipse modeling has partitioned into Java targeted implementation
modeling for which the Xxxxx tools provide excellent support and OMG
inspired specification modeling where users need to be more determined
and tolerant of tool quality.

You still have not provide a stack trace, so I guess that your problem
is that your Xpand activities are standalone rather than Eclipse-based
and so the plugin registrations are missing. You probably need at least

|org.eclipse.ocl.ecore.OCL.initialize(ResourceSet)|

|and|

||

|org.eclipse.ocl.ecore.delegate.DelegateDomain.initialize(ResourceSet)|.

See Standalone Configuration for Ecore in the OCL Documentation.

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 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
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 #857304 is a reply to message #857263] Thu, 26 April 2012 12:39 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4155
Registered: July 2009
Senior Member
Hi

at org.eclipse.emf.mwe.core.WorkflowRunner.main(WorkflowRunner.java:69)

is a very strong indication to me that you are running standalone.
Follow my earlier advice.

Regards

Ed Willink

On 26/04/2012 12:58, Missing name Mising name wrote:
> 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)
Re: [xPand] Access OCL derivation during generation [message #857432 is a reply to message #857304] Thu, 26 April 2012 14:29 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
Member
Thanks, I think I still do not fully understand the meaning of 'standalone'. However, switching to EmfRegistryMetaModel and calling an AbstractWorkflowComponent did the trick. Within the component, it was enough for me to call
EStructuralFeature.Internal.SettingDelegate.Factory.Registry.INSTANCE.put(OCLDelegateDomain.OCL_DELEGATE_URI, new org.eclipse.ocl.ecore.delegate.OCLSettingDelegateFactory.Global());


Is there a simpler way to do the standalone configuration, I mean without the AbstractWorkflowComponent?
Re: [xPand] Access OCL derivation during generation [message #857444 is a reply to message #857432] Thu, 26 April 2012 14:39 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4155
Registered: July 2009
Senior Member
Hi

Standalone is when you do not have automatic contribution of facilities
by Eclipse extension points; you must do it all manually. Yes I'm afraid
it is painful. My StnadloneProjecvtMap is a step in the direction of
making it easier.

You may think it is sufficient to install just OCLSettingDelegateFactory
rather than using the routine I suggested. It won't be long before you
complain that invariants and operation bodies don't work.

Regards

Ed Willink




On 26/04/2012 15:29, Missing name Mising name wrote:
> Thanks, I think I still do not fully understand the meaning of
> 'standalone'. However, switching to EmfRegistryMetaModel and calling
> an AbstractWorkflowComponent did the trick. Within the component, it
> was enough for me to call
> EStructuralFeature.Internal.SettingDelegate.Factory.Registry.INSTANCE.put(OCLDelegateDomain.OCL_DELEGATE_URI,
> new org.eclipse.ocl.ecore.delegate.OCLSettingDelegateFactory.Global());
>
> Is there a simpler way to do the standalone configuration, I mean
> without the AbstractWorkflowComponent?
Re: [xPand] Access OCL derivation during generation [message #874709 is a reply to message #857444] Mon, 21 May 2012 12:04 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4155
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 #874810 is a reply to message #874746] Mon, 21 May 2012 15:34 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
Member
I had a look at the OCL documentation for indigo, which seems to differ from your post in the call to org.eclipse.ocl.ecore.delegate.DelegateDomain.initialize(ResourceSet).

I tried to adjust the code by passing the ResourceSet from the WorkflowContext (ctx) to the initialization method.

ResourceSet set = ((EObject) ctx.get("model")).eResource().getResourceSet();
				
OCL.initialize(set);


Still getting the NullPointerException on execution with a non-dynamic model instance.
Re: [xPand] Access OCL derivation during generation [message #874825 is a reply to message #874810] Mon, 21 May 2012 15:51 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4155
Registered: July 2009
Senior Member
On 21/05/2012 16:34, Christopher G. wrote:
> I had a look at the OCL documentation for indigo, which seems to
> differ from your post in the call to
> org.eclipse.ocl.ecore.delegate.DelegateDomain.initialize(ResourceSet).
Ah! A Juno documentation bug fix. Applies to Indigo too.
>
> I tried to adjust the code by passing the ResourceSet from the
> WorkflowContext (ctx) to the initialization method.
>
>
> ResourceSet set = ((EObject)
> ctx.get("model")).eResource().getResourceSet();
>
> OCL.initialize(set);
>
>
> Still getting the NullPointerException on execution with a non-dynamic
> model instance.
Installed packages have a Resource but no ResourceSet.

When running standalone, there is little point using local ResourceSet
registrations; global is easier. Exception: long running server programs
should certainly use local ResourceSets.

Regards

Ed Willink
Re: [xPand] Access OCL derivation during generation [message #875813 is a reply to message #874825] Wed, 23 May 2012 11:14 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
Member
Hi,

I think my problem is rather caused by the fact that, in order to generate code from GMF-based models, I execute the workflow from a runtime instance of eclipse (that also runs the GMF editor). The template is located in the platform workspace and is called by a workflow from the runtime workspace. From here, not only GMF models but also the dynamic XMI models cause the NPE on access to the derived feature.

The org.eclipse.ocl.ecore.delegate.DelegateDomain.initialize(ResourceSet) method is not available to me.
I assume you refer to org.eclipse.ocl.examples.pivot.delegate.OCLDelegateDomain.initialize(ResourceSet). I copied all the initialization code from there and execute it using the correct delegateURI, without success.
Re: [xPand] Access OCL derivation during generation [message #875825 is a reply to message #875813] Wed, 23 May 2012 11:44 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4155
Registered: July 2009
Senior Member
Hi

I've no idea what software you're using which makes it very difficult to
comment constructively. You aklso provide no loadable code to examine.

I doubt that
org.eclipse.ocl.examples.pivot.delegate.OCLDelegateDomain.initialize(ResourceSet)
will do you any good since I doubt that any version of GMF has been
upgraded to use the pivot binding.

If org.eclipse.ocl.ecore.delegate.DelegateDomain.initialize(ResourceSet)
is not available then that is a big problem and the one you should be
solving. Not surprising it's not available because the routine I'm aware
of is in OCLDelegateDomain.

Where did you find the
"org.eclipse.ocl.ecore.delegate.DelegateDomain.initialize(ResourceSet)"
typo? apologies in advance if it was a recent message from me.

Regards

Ed Willink

On 23/05/2012 12:14, Christopher G. wrote:
> Hi,
>
> I think my problem is rather caused by the fact that, in order to
> generate code from GMF-based models, I execute the workflow from a
> runtime instance of eclipse (that also runs the GMF editor). The
> template is located in the platform workspace and is called by a
> workflow from the runtime workspace. From here, not only GMF models
> but also the dynamic XMI models cause the NPE on access to the derived
> feature.
>
> The
> org.eclipse.ocl.ecore.delegate.DelegateDomain.initialize(ResourceSet)
> method is not available to me. I assume you refer to
> org.eclipse.ocl.examples.pivot.delegate.OCLDelegateDomain.initialize(ResourceSet).
> I copied all the initialization code from there and execute it using
> the correct delegateURI, without success.
Re: [xPand] Access OCL derivation during generation [message #876376 is a reply to message #875825] Thu, 24 May 2012 13:31 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
Member
Hi,

the typo stems from this very thread (message 856148).

I figured out that the method OCLDelegateDomain.initialize(ResourceSet) is not in the latest release, but only in the 4.0.0 builds. Updating and calling it did not solve the issue, though.

For reproduction, I attached two zip files containing the projects for development workspace and runtime workspace (example models included). For both cases there are workflows running the generator with dynamic and non-dynamic instances.

What I would expect is at least a working generator for the dynamic instance from development workspace, and for the non-dynamic model from runtime workspace. The only working combination is with the dynamic instance from development workspace. All others fail.


Thanks in advance for further hints.


  • Attachment: dev.zip
    (Size: 127.70KB, Downloaded 83 times)
  • Attachment: runtime.zip
    (Size: 6.73KB, Downloaded 81 times)
Re: [xPand] Access OCL derivation during generation [message #879214 is a reply to message #854755] Wed, 30 May 2012 19:12 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
Member
Don't want to act impatient, but has any of the downloaders tried to run the example workflows? If so, thanks for the effort. Did you experience the same errors that I did?
Re: [xPand] Access OCL derivation during generation [message #880000 is a reply to message #879214] Fri, 01 June 2012 09:02 Go to previous messageGo to next message
Karsten Thoms is currently offline Karsten ThomsFriend
Messages: 360
Registered: July 2009
Location: Dortmund
Senior Member

Only had a quick look. It requires OCL 3.2.0, but I had only 3.1.2 from Indigo. I did not have the time to set up a proper target platform for that.

Need professional support for Xtext, Xpand, EMF?
Go to: http://xtext.itemis.com
Twitter : @kthoms
Blog : www.karsten-thoms.de
Re: [xPand] Access OCL derivation during generation [message #880004 is a reply to message #880000] Fri, 01 June 2012 09:06 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4155
Registered: July 2009
Senior Member
Hi

Is there some Xpand support for OCL that I'm unaware of?

I couldn't understand the previous message about example workflows at all.

Regards

Ed Willink

On 01/06/2012 10:02, Karsten Thoms wrote:
> Only had a quick look. It requires OCL 3.2.0, but I had only 3.1.2
> from Indigo. I did not have the time to set up a proper target
> platform for that.
Re: [xPand] Access OCL derivation during generation [message #880056 is a reply to message #880004] Fri, 01 June 2012 10:44 Go to previous messageGo to next message
Karsten Thoms is currently offline Karsten ThomsFriend
Messages: 360
Registered: July 2009
Location: Dortmund
Senior Member

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, Xpand, EMF?
Go to: http://xtext.itemis.com
Twitter : @kthoms
Blog : www.karsten-thoms.de
Re: [xPand] Access OCL derivation during generation [message #881290 is a reply to message #880056] Mon, 04 June 2012 09:43 Go to previous message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 41
Registered: April 2011
Member
Karsten,

changing from the AbstractWorkflowComponent to a Bean solves the whole problem immediately. No idea why this makes any difference, though.

Thanks for your hint anyway!
Previous Topic:[Xpand] How to indicate progress while executing a template ?
Next Topic:Porting Xpand to Xtend2
Goto Forum:
  


Current Time: Sat Nov 29 10:16:45 GMT 2014

Powered by FUDForum. Page generated in 0.05420 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software