Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 355188

Summary:

Provide a way to add dynamicFeatures to a static EClass

Product:

[Modeling] EMF

Reporter:

Mickael Istria <mistria>

Component:

Core

Assignee:

Ed Merks <Ed.Merks>

Status:

RESOLVED WONTFIX

QA Contact:

Severity:

enhancement

Priority:

CC:

gdupe, marc.dutoo

Version:

unspecified

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Draft of modifications to support extensible models.	none

Description Mickael Istria

2011-08-19 04:01:26 EDT

Created attachment 201768 [details]
Draft of modifications to support extensible models.

For the following use case:
I get an EObject o from a 3rd-party bundle, in a metamodel that is not owned by me. This metamodel is too poor, I'd like to extended with some vendor-specific specific (for example an attribute with the ExtendedMetaData set in order to get it well serialized in XML).
That, way I can use the provided object as I want, and leverage stuff such as EMF-Databinding when editing the vendor-specific extensions of this EObject

As discussed on forum ( http://www.eclipse.org/forums/index.php/t/235670/ ), this was leading to a StackOverflowException in EMF, because of a bug in the way a feature is checked as dynamic or not.

Then I made some changes to the Ecore plugin to add the capacity to add explicitly dynamic features to static classes, and it works well for my use-case.

In the attached zip, changes are done in EClass, EClassImpl and BasicEObjectImpl

Comment 1 Mickael Istria

2011-08-19 04:05:33 EDT

Here is the client code I use to add extension to the metamodel: JbiPackage.Literals.CONSUMES.eAddDynamicFeature(Cdk5Package.Literals.CDK5_CONSUMES__OPERATION);

Comment 2 Ed Merks

2011-08-19 12:05:18 EDT

Sorry, but adding support in the core for modifying a generated model is just not something I'm going to consider.  Any class down stream in the inheritance from a dynamically extended class will find that its getEAllStructuralFeatures list has changed and hence the indexes of all its local features have shifted such that they will not be properly switched in the generated reflective accessors. The whole notion of allowing an arbitrary number of downstream clients to modify a shared base model with their own contributions just sounds like a formula for chaos to me.  How to do so such modifications to what's supposed to be a read-only model and do so in a thread-safe deterministic way.  How to avoid and detect conflicts in the new features?  How to ensure that serialized instances can be read when some of the contributions might be absent elsewhere or later?  It's just a path to hell, no matter how good the intention.