Community
Participate
Working Groups
Following this discussion: http://www.eclipse.org/forums/index.php/t/272881/ The idea is to be able to create dynamic attributes to static generated types, and to be able to annotate these new attributes in order to be able to perform eSet(...) of this attributes on the static type. The static type must provide extensibility via FeatureMaps.
The following branch contains an "AffiliationTest" class that explicit the use-cases in 2 failing test-cases. https://github.com/mickaelistria/EMF/tree/369264
I'm not a git expert. I really don't know what to do with this git link. I also don't have a lot of free time... I doubt this is really a bug. Only features from a document root can be affiliated. You can make a feature map corresponding to a very permissive wildcard that allows elements from any namespace thereby allowing you to add new features from a new package with a new document root. You can see how BasicExtendedMetaData.demandFeature creates such new features on demand in order to support lax wildcards.
(In reply to comment #2) > I'm not a git expert. I really don't know what to do with this git link. I > also don't have a lot of free time... I'll attach it as a patch then. > > I doubt this is really a bug. Only features from a document root can be > affiliated. Ok, so this is not a bug. This is rather a limitation. Is it a necessary one? Could we get rid of it to allow more power inside EMF ? > You can make a feature map corresponding to a very permissive > wildcard that allows elements from any namespace thereby allowing you to add > new features from a new package with a new document root. I already tried this, but found it too difficult and constraining for my use-case. The use-case is to be able to specify a target feature map from a dynamic attribute. > You can see how BasicExtendedMetaData.demandFeature creates such new features > on demand in order to support lax wildcards. I'll have a look at this.
Created attachment 209909 [details] Test case, as a patch Patch in Git Format. Apply with "git apply".
Just the fact that you've done this: // Make extension featureId to -1 to make them dynamic ((EAttributeImpl)TestExtensionViaAffiliationPackage.Literals.EXTENSION_TYPE__EXTENSION1).setFeatureID(-1); ((EAttributeImpl)TestExtensionViaAffiliationPackage.Literals.EXTENSION_TYPE__EXTENSION2).setFeatureID(-1); makes it glaringly the case that you've strayed off the beaten path. EMF generates an feature of ID -1 only for features of a document root for a reason. Only features of a document root can be affiliated with classes that don't actually own the feature (the feature is not among the eAllStructuralFeatures). Next you've forced something that isn't a document root to be one anyway but giving it a blank name. Sorry but EMF is not intended to be used this way. You'll need to define a proper document root in a package of its own.
Ok, Then I gave some tries using a Mix of static EMF and features created dynamically using EcoreFactory. Everything would work fine if there was not this "isDocumentRoot(eStructuralFeature.getEContainingClass())" check. (In this use case "work fine == add dynamic feature to static type, if necessary through feature maps") What does this check avoids? Why preventing features to be added to items that are not DocumentRoot? I think this is the core of the EMF-Facet project: provide extensibility to existing model items. And I now think this simple check is the only thing that prevents EMF to support this.
This check ensures that only features *from* a document root, i.e., features corresponding to global element declarations in an XML Schema, can be used in wildcards. It's not guarding what such features can be added to; the wildcard information (the allowed namespace) will guard for that. When deserializing XML this type of information is important, i.e., the lookup for the feature has to find a package for the namespace, the document root for that package, and then find the feature with that name in the document root.
