Marc,
Comments below.
Marc Dutoo wrote:
Hi
all
Please reply to this message instead so it also get posted in JWT's
forum.
Regards,
Marc
Marc Dutoo a écrit :
Hi all
In the project Eclipse JWT, we manage workflows using ecore-specified
XMI models and we want to let our users define and add custom
information in it.
We've logically though about allowing to define ecore metamodels than
extend ours, and about the possibilities of Dynamic EMF. So we've tried
a few things (using Europa's EMF) and come across what seem to be
limitations of extending EMF, especially concerning typing of relations
:
* a dynamic class can only extend a non-interface, non-abstract
static class. OK, actually I can agree with this one ;)
Yep. That's because it needs to be able to create an instance of the
Impl class that it can extend. In hindsight, for dealing with proxies,
it would have been nicer if you could always create an instance of even
an abstract class, but some internal mechanism, but this would force
clients to always provide a non-abstract impl class; it's too late to
foist that on clients now.
* in order to create dynamic extensions inheriting from this
non-interface, non-abstract static class, I've had to create and
register a custom factory that does this work for the package
containing the dynamic ecore extension. Well, ok again, we could
automatically do this for all ecores that are found in a given place.
No, this logic in EFactoryImpl should do the trick of creating an
instance of the first super type with an implementation class.
public EObject create(EClass eClass)
{
if (getEPackage() != eClass.getEPackage() ||
eClass.isAbstract())
{
throw new IllegalArgumentException("The class '" +
eClass.getName() + "' is not a valid classifier");
}
for (List<EClass> eSuperTypes =
eClass.getESuperTypes(); !eSuperTypes.isEmpty(); )
{
EClass eSuperType = eSuperTypes.get(0);
if (eSuperType.getInstanceClass() != null)
{
EObject result =
eSuperType.getEPackage().getEFactoryInstance().create(eSuperType);
((InternalEObject)result).eSetClass(eClass);
return result;
}
eSuperTypes = eSuperType.getESuperTypes();
}
return basicCreate(eClass);
}
* Now to the fun stuff : I defined in a dynamic EMF extension to my
core, static metamodel a containment eReference that whose target type
is a core, static type, but any sample model fails to load. It appears
that proxy resolution fails for my eReference at parsing : it goes
through XMLHandler.setFeatureValue()'s proxy handling code at line 2628
where either createObjectFromFeatureType() believes the eReference's
eType is eClassifier (because it is the type of the "eType" feature of
EReference), or createObjectFromTypeName() believes the eReference's
eType is PropertyImpl (whereas it should be a ClassImpl with name
Property).
What's PropertyImpl? It sounds like some crossing of meta model
boundaries here.
* and upside down, I defined a core, static-typed element under a
dynamic defined, but was not able to load a sample following this
model, for the same reason. Though proxy resolution works fine for
attributes, or if typing the dynamic-defined relation with a
dynamic-defined extension of a core, static type.
Any feedback about this behaviour ?
I'm totally confused. :-P
Maybe you could be a bit more concrete about the nature of these
extensions you wrote. Generally EMF won't care if the type of an
EReference is a dynamic EClass or a static EClass. BUT, it's
important that if you want to static EClass, your Ecore model needs to
refer to that static model (via the nsURI) and not tot he dynamic model
(i.e., the serialized .ecore version in the model folder).
NB. for those more interested about the "requirements" side of our
endeavours, you can look here see more here
http://wiki.eclipse.org/JWT_Metamodel .
Regards,
Marc Dutoo
Open Wide
Eclipse JWT co-lead
|