| [xPand] Access OCL derivation during generation [message #854755] |
Tue, 24 April 2012 04:05  |
Eclipse User |
|
|
|
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 04:06] by Moderator |
|
|
| Re: [xPand] Access OCL derivation during generation [message #855107 is a reply to message #854755] |
Tue, 24 April 2012 10:24  |
| Eclipse User |
|
|
|
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 #874709 is a reply to message #857444] |
Mon, 21 May 2012 08:04 |
| Eclipse User |
|
|
|
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 08:58] by Moderator |
|
|
| Re: [xPand] Access OCL derivation during generation [message #874746 is a reply to message #874709] |
Mon, 21 May 2012 09:28 |
| Eclipse User |
|
|
|
<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>
|
|
|
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.05923 seconds
Home