|
|
| Re: Helios OCL Console / CompleteOCL Editor against workspace metamodels [message #662765 is a reply to message #662740] |
Thu, 31 March 2011 20:28   |
 Adrian Price
Messages: 61
Registered: July 2009 |
Member |
|
|
Hi Ed,
Thanks for the quick response.
I tried that but unfortunately although that works in the devbench (IDE)
it fails in the runbench/binbench (application). Some of these OCL files
are necessarily in different plug-ins to the Ecore model that they
constrain, so for example the relative path
import '../com.tibco.forms.model.form/model/form.ecore'
fails at run-time with the exception:
org.eclipse.ocl.SyntaxException: 1:1:1:55 "import
'../com.tibco.forms.model.form/model/form.ecore'" unexpected token(s)
at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:307 )
at org.eclipse.ocl.OCL.parse(OCL.java:274)
at
com.tibco...ocl.OCLConstraintProvider.parseConstraints(OCLCo nstraintProvider.java:226)
....
org.eclipse.emf.validation.internal.service.ProviderDescript or.getProvider(ProviderDescriptor.java:268)
Conversely, importing the EPackage::nsURI or EPackage::name seems to
work only at run-time. Hence it seemed to me that the only resolution to
the problem would lie in configuring the DT OCL Model Registry.
Anyhow thanks for your comments, I guess this is another good reason to
port to Indigo :-)
Cheers,
--A
BTW we met last week at EclipseCon - good to put a face to a name! :-)
On 31/03/2011 18:49, Ed Willink wrote:
> Hi Adrian
>
> Loading Complete OCL into the Console has been a longstanding problem,
> which is potentially fixed in Indigo M6 for which the OCL Xtext Console
> has a Load Resource capability (exercised rather than tested at present).
>
> Merging the registries would be a good idea; one of my personal
> enthusiasms that I have difficulty getting others to appreciate the need
> for. The OCL Registry started as the UMLX registry then moved to QVTd. A
> further migratiion to an EMF Registry project failed to gain support so
> it had to move to the OCL Registry instead.
>
> In the Complete OCL editor you can use an import statement rather than a
> registration. See the RoyalAndLoyal example project that installs on
> Helios; it is temporarily missing from the Indigo build.
>
> Regards
>
> Ed
>
> On 31/03/2011 17:41, Adrian Price wrote:
>> Good day MDT/OCL,
>>
>> I'm trying to use the Interactive OCL Console and CompleteOCL Editor
>> in a Helios SR-1 devbench to develop invariants against two related
>> Ecore metamodels *in the devbench workspace*. Neither console nor
>> editor seems to recognize the metamodels, despite my having created
>> both 'Model Name' (the Ecore package name) and 'URI' (the Ecore
>> package nsURI) platform:/resource/... entries in the project's OCL
>> Model Registry. I let it add the xtextNature and xtextBuilder to the
>> project but they made no difference. BTW any plans for a
>> workspace-wide registry?
>>
>> BTW I am developing plug-ins and the PDE target platform is
>> Eclipse-3.4 (although I doubt that this would be relevant).
>>
>> Could anyone tell me what I am doing wrong?
>>
>> Thanks in advance,
>>
>> Adrian Price
>> Senior Architect
>> TIBCO Software Inc.
>>
>> P.S. I'm also successfully using QVTo, which has its own metamodel
>> registry - are there any plans to merge/integrate the OCL & QVTo
>> registries?
>
|
|
|
| Re: Helios OCL Console / CompleteOCL Editor against workspace metamodels [message #662769 is a reply to message #662765] |
Thu, 31 March 2011 20:52 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Adrian
You might want to look at my EclipseCon tutorial slides where I showed
how to use the model registry to ensure that 'http:/...' could be used
to support import into the Xtext *.ocl file in both workspaces. I think
it's the same problem.
In Helios, the OCL Xtext editor was a late redevelopment to overcome
release train dependency problems with an IMP-based predecessor. The
editor was not fully integrated, started at M6 and only became useable
at about RC1; it edits and parses syntax only. To execute, you reparse
with the old LPG parser, which does not support the import statement.
This is your syntax error. You must comment out the import to use the
LPG parser and use the model registry.
[I considered resolving this asymmetry, but at Helios RC2, it was
getting too late to add an import statement to the frozen code, and
anyway the OCL editor was not fully integrated anyway. Sorry.]
Regards
Ed
On 31/03/2011 21:28, Adrian Price wrote:
> Hi Ed,
>
> Thanks for the quick response.
>
> I tried that but unfortunately although that works in the devbench
> (IDE) it fails in the runbench/binbench (application). Some of these
> OCL files are necessarily in different plug-ins to the Ecore model
> that they constrain, so for example the relative path
>
> import '../com.tibco.forms.model.form/model/form.ecore'
>
> fails at run-time with the exception:
>
> org.eclipse.ocl.SyntaxException: 1:1:1:55 "import
> '../com.tibco.forms.model.form/model/form.ecore'" unexpected token(s)
> at org.eclipse.ocl.util.OCLUtil.checkForErrors(OCLUtil.java:307 )
> at org.eclipse.ocl.OCL.parse(OCL.java:274)
> at
> com.tibco...ocl.OCLConstraintProvider.parseConstraints(OCLCo nstraintProvider.java:226)
> ....
> org.eclipse.emf.validation.internal.service.ProviderDescript or.getProvider(ProviderDescriptor.java:268)
>
>
> Conversely, importing the EPackage::nsURI or EPackage::name seems to
> work only at run-time. Hence it seemed to me that the only resolution
> to the problem would lie in configuring the DT OCL Model Registry.
>
> Anyhow thanks for your comments, I guess this is another good reason
> to port to Indigo :-)
>
> Cheers,
>
> --A
>
> BTW we met last week at EclipseCon - good to put a face to a name! :-)
>
>
> On 31/03/2011 18:49, Ed Willink wrote:
>> Hi Adrian
>>
>> Loading Complete OCL into the Console has been a longstanding problem,
>> which is potentially fixed in Indigo M6 for which the OCL Xtext Console
>> has a Load Resource capability (exercised rather than tested at
>> present).
>>
>> Merging the registries would be a good idea; one of my personal
>> enthusiasms that I have difficulty getting others to appreciate the need
>> for. The OCL Registry started as the UMLX registry then moved to QVTd. A
>> further migratiion to an EMF Registry project failed to gain support so
>> it had to move to the OCL Registry instead.
>>
>> In the Complete OCL editor you can use an import statement rather than a
>> registration. See the RoyalAndLoyal example project that installs on
>> Helios; it is temporarily missing from the Indigo build.
>>
>> Regards
>>
>> Ed
>>
>> On 31/03/2011 17:41, Adrian Price wrote:
>>> Good day MDT/OCL,
>>>
>>> I'm trying to use the Interactive OCL Console and CompleteOCL Editor
>>> in a Helios SR-1 devbench to develop invariants against two related
>>> Ecore metamodels *in the devbench workspace*. Neither console nor
>>> editor seems to recognize the metamodels, despite my having created
>>> both 'Model Name' (the Ecore package name) and 'URI' (the Ecore
>>> package nsURI) platform:/resource/... entries in the project's OCL
>>> Model Registry. I let it add the xtextNature and xtextBuilder to the
>>> project but they made no difference. BTW any plans for a
>>> workspace-wide registry?
>>>
>>> BTW I am developing plug-ins and the PDE target platform is
>>> Eclipse-3.4 (although I doubt that this would be relevant).
>>>
>>> Could anyone tell me what I am doing wrong?
>>>
>>> Thanks in advance,
>>>
>>> Adrian Price
>>> Senior Architect
>>> TIBCO Software Inc.
>>>
>>> P.S. I'm also successfully using QVTo, which has its own metamodel
>>> registry - are there any plans to merge/integrate the OCL & QVTo
>>> registries?
>>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03386 seconds
] 
Search
Help
Register
Login
Home
