Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Import statement and obsolete examples plugins 
Hi Ed,
Xtext's imports are just a convenient default. There is no need to use them. A viable alternative is to implement a custom ScopeProvider that provides EObjectDescriptions for the Ecore files in your workspace. As the Xtext framework will pick up those resources automatically if the project has the appropriate nature assigned, there is no need to hassle with workspace traversal or complicated external configuration. Just query the IResourceDescriptions for all instances of EPackage and you'll get the answer for the development environment, and ask the EPackage.Registry to obtain the EPackages in the actually running Eclipse, too. Because scopes can be nested into each other, it's very easy to implement a shadowing semantic and prioritize the EPackages in your workspace higher than the ones from the registry in case of name- clashes. 

Regards,
Sebastian


On 25.04.2010, at 11:08, Ed Willink wrote:


Hi
Xtext is very keen on import statements and provides good support for them.
The lack of an import statement in CompleteOCL and QVTc and QVTr was my motivation for the two level name resolution supported by the Model Registry. I am finally coming round to Ed Merks' thinking that this problem is a bug in CompleteOCL and QVTd.
An import (meta-model) and include (more CompleteOCL) issue is pending at OMG as Issue 14599.
The new Xtext CompleteOCL and OCLinEcore editors uses an import statement. If you're using plugins then it's 

   import ecore : 'http://www.eclipse.org/emf/2002/Ecore'

if you're just developing it's

   import mine : 'platform:/resource/MyMetaModel'
This gives us the slightly embarrassing situation that CompleteOCL developed with the Xtext editor and using an import statement, cannot be parsed as an OCL document by the LPG parser.
Currently it is a user responsibility to define the EMF registry of a CompleteOCL parse to resolve needed meta-models and unfortunately the way this is done is different for Ecore and UML. 

I see three options:

a) Do nothing. Xtext is only an example. It is not fully integrated.
b) Add parsing that ignores an import statement to the LPG parser. A bit close to M7, but it only affects the CompleteOCL grammar. Users still need to configure the LPG environment.
c) Fully support an import statement in the LPG parser. As above, but we also need to load the registry, eliminating the need for users to configure registries externally.
I favour b), creeping to c) if time allows, with an intent to have c) in 3.0.1. 

----------------
Elimination of the IMP editors renders the org.eclipse.ocl.examples.parser.* plugins redundant, which in turn leaves the org.eclipse.ocl.examples.modelregistry.* plugins redundant, and if OCL (and QVTd) has an import statement there is limited motivation to reintroduce it.
QVTd has not yet migrated to exploit the OCL Model Registry and I would be amazed if anyone else has. QVTo is not affected.
I favour dropping the org.eclipse.ocl.examples.editor.*, org.eclipse.ocl.examples.parser.* and org.eclipse.ocl.examples.modelregistry.* plugins. 

   Regards

       Ed Willink




_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev

Back to the top