Community
Participate
Working Groups
An NPE is encountered when UMLModelWizard fails to retrieve a default editor for *.uml file extension; this has happens with UML2 and EMF Compare installed. EMF Compare contributes a locked content type association for *.uml files. As a result, the content type of *.uml files is org.eclipse.emf.compare.ui.contenttype.ModelContentType and the editor registry is unable to locate a default editor for that content type; see org.eclipse.ui.internal.registry.EditorRegistry#getDefaultEditor(String) for details.
I'll always be amazed by the number of issues the whole "content-type" thing sports ... Contribute a content-type, and Eclipse locks all extensions you contribute by default, have multiple content-types for a given file, and most code depending on it will simply rule out all other than the first returned ... Useless rambling appart ... I've never been faced with this issue, be it with uml or ecore : we also "hijack" the ecore content-type, yet the ecore editor is opened as expected when opening an "ecore" file. The same is true for UML : if I have both UML and EMF Compare installed, the UML model editor is still opened by default when I open an "uml" file. This holds true on all Eclipses EMF Compare is compatible with : 3.4, 3.5 and 3.6(M6). Seems the issue is triggered only when creating a new UML file, I'll try and see if 1) I can reproduce and 2) we're the culprit there.
The problem is not the UML editor but the UML (and possibly even Ecore) model file creation wizard. See #277623 for details (i.e., exception stack trace).
Once again ... org.eclipse.core.internal.content.ContentTypeMatcher#findContentTypeFor(String) discards all additional content-types except for the very first. This is what's called by "EditorRegistry#getDefaultEditor(String)". That last method could (should) check each content types returned by ContentTypeMatcher#findContentTypesFor(String) (note the additional "s") and return the first editor found instead of simply returning "null" if the very first content-type has no editor associated ... Whatever. Double clicking a ".uml" file in the worskpace opens the accurate editor. Why isn't that the same result when using the "new uml file" wizard? The code they use seem a little smarter, the patch I attached to bug 277623 will show the code that is to be modified in your wizard to properly open the UML editor when clicking finish (different code could be used, but I tried to stay close to what you had). This is a WONTFIX for EMF Compare as the problem should be handled from your side : true, it's been detected because EMF Compare registers ".uml" files against its own content type ... but you would have the exact same issue if anyone registers ".uml" against any content type that doesn't provide its own editor (try this by adding it to the "word document" content type). PS: you've added a comment while I was writing this. The "new ecore file" wizard doesn't sport the same issue as yours ; they do check for null before getting the editor id. If you'd rather use a code similar to theirs instead of the patch I'll attach to your bug, take a look at EcoreModelWizard line 320.
