[
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