The only specific thing is that Kind extends EClassifier.
I generate EMF projects (emf, edit editor and tests).
When I want to create a conforming model, the kind instance doesn't appear correctly in my editor.
It appears like that "metamodel.impl.KindImpl@7c9eb178 (name: null) (instanceClassName: null) (ktitle: null)
While struggling with an OCL aspect of your example as part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=513479 I found that there seems to be something magic about "Extension" whereby Extension.xmi was determinedly loaded even after I renamed everything and restarted Eclipse. I couldn't reproduce in a nested Eclipse and so couldn't debug further.
While endeavoring to repro this problem I get clobbered by Extension.xmi again. But I think what you observe is correct. The default editor will use a default naming for a multi-String class. I suspect that you misleadingly refer to the dsl editor implying the generated editor for use in a nested Eclipse when you mean the default editor in the current Eclipse.
Anyway, as Ed M reminds you, extending Ecore is really bad. Bug 513479 points out that your Extension-contains-EClassifier-but-does-not-extend-EPackage breaks Ecore practice.
If you want a new metamodel, design it independently of Ecore. If you want something horrendously extensible use XML. But much better, rethink your problem and use Ecore conventionally.
So, the done scenario was
1- I create a metamodel
2- I create emf project
3- I generate projects (edit editor and test)
4- I run Runtime Eclipse (EMF project right click run as Eclipse Application)
5- I create a model using the DSL editor (metamodel editor) in the runtime eclipse
6- I create a model
7- I create an extension instance
8- Then extension -> "New Child" Kind
9-The strange behavior appears (Please see the joined image).
You can find my code (emf projets) in the zipped attachment.
If you're going to extend Ecore's class (i.e., not just reference classifiers as type type of a typed elements), you should reconsider. If you feel you must go against that advice, then you must use the development time version of the Ecore model and your GenModel must use Ecore's GenModel. So your Ecore model must look like this:
Note in particular the reference to ../../org.eclipse.emf.ecore/model/Ecore.ecore#//EClassifier (resolves in the development time version in the workspace or target platform) rather than the reference to http://www.eclipse.org/emf/2002/Ecore#//EString which resolves to the runtime instance (EcorePackage.eINSTANCE in the running IDE). When done this way, the GenModel will include usedGenPackages="../../org.eclipse.emf.ecore/model/Ecore.genmodel#//ecore" (i.e., it will reference Ecore's GenModel) and the generated KindItemProvider will extend org.eclipse.emf.ecore.provider.EClassifierItemProvider.
please another question.
I create metamodel with reference to ../../org.eclipse.emf.ecore/model/Ecore.ecore#//EClassifier and It works perfectly.
However, when I open the metamodel with OCLinEcore editor and I do some changes, the reference changes automatically to http://www.eclipse.org/emf/2002/Ecore##//EClassifier.
I meant, is there an org.eclipse.emf.ecore/model/Ecore.ecore in an open project. Is there an org.eclipse.emf.ecore/model/Ecore.ecore in a closed project?
One of EMF's weaknesses is the ability to refer to the same model element in too many different ways leading to multiple model loading and confusing X is not equal to X diagnostics. OCL tooling fights this metamodel schizophrenia by 'merging' all EPackages with identical nsURIs. This is often helpful, but needs enhancement to allow distinct user/tooling merges (Bug 510503).
In your case, by referring to ../../org.eclipse.emf.ecore/model/Ecore.ecore, you are using a potentially locally modified version of Ecore. If you are developing Ecore, this may be appropriate. However since I presume that you are just using Ecore, you should not stress tools by pretending that you are using a variant. Use http://www.eclipse.org/emf/2002/Ecore.